Forum: Mikrocontroller und Digitale Elektronik Welche Programmiersprache soll ich lernen?


von A-Freak (Gast)


Lesenswert?

Einen guten Morgen

Ich möchte noch einmal versuchen in moderne Mikrocontroller 
einzusteigen, Schwerpunkt wären ATTiny zur Ablaufsteuerung und 
Signalverarbeitung.

Mein Fachgebiet liegt sonst bei Analogtechnik und HF.

"Damals als ich noch jung war" konnte ich ziemlich gut BASIC und ein 
bißchen Assembler.

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?

Besonder gut wäre wenn diese nativ für Ubuntu verfügbar sind und keinen 
Zwang zu Registrierung und Onlinebindung haben.

"C" und verwandte Sprachen muß ich ausschließen. 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 
Algorithmen und Abläufe sehr gut bekannt.

Programmcode sollte ungefähr so aussehen

Lesetemperatur:
  Rohwert=ADC(3)
  TemperaturinCelsius=Rohwert*1.11-68



Mit freundlichen Grüßen vom A-Freak

:
von Alles klar (Gast)


Lesenswert?

C, was sonst?

von PittyJ (Gast)


Lesenswert?

Sobald du auch nur irgendeine Hardware ansprechen möchtest, kommst du um 
C nicht herum. Alle Bibliotheken dafür basieren zu 99 Prozent auf C. 
Dokumentation ist C usw.

Vergiss die Nischenprodukte wie Bascom. Sobald du die Plattform 
wechselst, steht es nicht mehr zur Verfügung und du mußt etwas neues 
lernen.
Also am besten gleich C.

von Dr. Sommer (Gast)


Lesenswert?

A-Freak schrieb:
> Casten

Sprachen ohne Casts sind also solche ohne Typisierung. Da fielen mir PHP 
und JS ein. Die haben natürlich nichts mit Embedded zu tun, und haben 
auch die C-artige Syntax. Untypisierte Sprachen sind aber letztendlich 
komplizierter als typisierte, weil sie oft unerwartetes Verhalten zeigen 
und man sich den Kopf zerbricht warum...

A-Freak schrieb:
> Void()
Was ist das, hab ich noch nie gesehen?

A-Freak schrieb:
> "=" versus "=="

Pascal, Ada. Aber die haben Casts (streng typisiert).

A-Freak schrieb:
> Klammer-Konstruktionen
Schreibst du Mathematische Ausdrücke auch immer ohne Klammern? Also 
(a*(b+c^ln(5))) ist zu kompliziert? Solche Ausdrücke sind es eigentlich, 
die textuelle Sprachen mächtig machen... nur halt manche Opas wie Basic 
nicht.

von Rolf M. (rmagnus)


Lesenswert?

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?

: Bearbeitet durch User
von Zille (Gast)


Lesenswert?

A-Freak schrieb:
> ATTiny

Wenn Du kein C magst, dann bleibt bei den 8 Bit Controllern eigentlich 
nur noch Assembler. Allerdings würde ich dann über PIC-Controller statt 
über den ATTiny nachdenken. Der Assembler-Befehlssatz umfasst bei den 
PICs nur etwas über 30  unterschiedliche Befehle und ist somit (im 
Gegensatz zum ATTiny-Assembler) sehr schnell gelernt. Zudem ist er 
leistungsfähiger, da er z.B. auch einen Multiplikationsbefehl 
beinhaltet.

von Karl K. (karl2go)


Lesenswert?

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.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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

von Augenverdreher (Gast)


Lesenswert?


von Karl K. (karl2go)


Lesenswert?

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.

von hilti (Gast)


Lesenswert?

Hallo,

falls Du ausschliesslich AVRs programmieren möchtest, kannst Du Dir mal 
Luna anschauen:

http://avr.myluna.de

von georg (Gast)


Lesenswert?

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

Ich habe Z80 sehr effektiv in Pascal programmiert, aber das ist durch 
die Tätigkeit von Embarcadero wohl dem Untergang geweiht (den sehr guten 
Prospero-Compiler für Z80 gibt es sowieso schon lange nicht mehr). Aber 
egal, im Embedded-Bereich muss man unbedingt C zumindest AUCH 
beherrschen, wenigstens lesen können - auch wenn C von vielen eher dazu 
verwendet wird, die Funktion eines Programms zu verschleiern.

Georg

von Barrex (Gast)


Lesenswert?

@A-Freak
Was nicht so ganz eindeutig aus Deinem Post hervorgeht, ob Du Dich 
privat oder beruflich damit beschäftigen möchtest.

Privat zählt natürlich in erster Linie der Spass, wenn freepascal mit 
avr's umgehen kann, warum nicht.

Beruflich würde ich aber auf alle Fälle C verwenden. Da geht es um 
Austauschbarkeit mit Kollegen/Kunden, Wiederverwendung, und dem Einsatz 
von fertigen Bibliotheken. Da ist einfach die Spielwiese insgesamt 
grösser.

von Peter D. (peda)


Lesenswert?

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.

von Dr. Sommer (Gast)


Lesenswert?

Karl K. schrieb:
> "Solche Ausdrücke" konnte Opas AmigaBasic schon vor 30 Jahren, und
> andere Basics auch.

Bascom aber offenbar schon nicht. Ziemlich arm, denn das Parsen solcher 
Ausdrücke ist keine Raketenwissenschaft - lernt man selbst an der FH im 
1. Semester Bachelor Informatik...

Karl K. schrieb:
> Und was der TO wahrscheinlicher meint, sind die {{({})(())}}
> Klammerorgien in C.
Das ist kein gültiger C Code. Irgendeine Form von Klammerung hat jede 
Sprache. Ist das jetzt so ein Unterschied ob da "{" oder "begin" steht? 
Sind nicht andere Dinge wichtiger - z.B. ob innerhalb der Klammern 
definierte Variablen außerhalb sichtbar sind?

von Manfred F. (manfred_f)


Lesenswert?

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.

von P.Loetmichel (Gast)


Lesenswert?

> Bascom aber offenbar schon nicht.

Klammern braucht man halt nicht.
Wenn man den Ausdruck zeilenweise auswertet.

90 % aller Profis programmieren in BASCOM!

von Dr. Sommer (Gast)


Lesenswert?

P.Loetmichel schrieb:
> Klammern braucht man halt nicht.
> Wenn man den Ausdruck zeilenweise auswertet.

Fahrzeuge braucht man auch nicht, wenn man überall zu Fuß hingeht!

Beitrag #5530988 wurde von einem Moderator gelöscht.
Beitrag #5530990 wurde von einem Moderator gelöscht.
von Cyblord -. (cyblord)


Lesenswert?

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?

von Christian M. (Gast)


Lesenswert?

Dr. Sommer schrieb:
> A-Freak schrieb:
>> Void()
> Was ist das, hab ich noch nie gesehen?

Also noch nie C gesehen...

Dr. Sommer schrieb:
> A-Freak schrieb:
>> Klammer-Konstruktionen
> Schreibst du Mathematische Ausdrücke auch immer ohne Klammern?

Er meint geschweifte Klammern!

Dr. Sommer schrieb:
> weil sie oft unerwartetes Verhalten zeigen und man sich den Kopf
> zerbricht warum...

Ja genau das Gegenteil ist der Fall! In Pascal und BASIC weisst Du was 
Du machst!

Ich programmiere Mikrocontroller seit immer IN BASIC, und bin gut 
gefahren. Dass man für jedes simple I2C-Device eine Bibliothek braucht, 
ist Arduino - mässige Inkompetenz.

@TO: Nimm einen Compiler von MikroE oder Oshionsoft.

Gruss Chregu

Beitrag #5530996 wurde von einem Moderator gelöscht.
von Route_66 H. (route_66)


Lesenswert?

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.

von Dr. Sommer (Gast)


Lesenswert?

Christian M. schrieb:
> Also noch nie C gesehen...

Ich hab schon sehr viel C gesehen, aber "Void ()" noch nicht. Es sei 
denn, man definiert eine Funktion namens "Void" und ruft sie mit "Void 
()" auf. Dann ist mir aber nicht klar, was daran schlimm sein soll.

Christian M. schrieb:
> Er meint geschweifte Klammern!
Sprachen ohne Klammern (oder begin/end-Äquivalent) erlauben nur 
grausamen Spaghetti-Code. Davon gibt's auch nur sehr wenige, wie z.B. 
"LOGO" (hat nix mit Siemens Logo zu tun), aber selbst das hat so etwas 
ähnliches. Das ist übrigens auch untypisiert - genau das was der TO 
will. Läuft auch nur unter DOS. Ich durfte das mal zu Schulzeiten 
benutzen und habe mich gefragt, wie jemand so eine bescheuerte Sprache 
erfinden kann.

Christian M. schrieb:
> Ja genau das Gegenteil ist der Fall! In Pascal und BASIC weisst Du was
> Du machst!
Die sind aber statisch typisiert, brauchen also Casts, und haben auch 
Klammern.

Christian M. schrieb:
> Ich programmiere Mikrocontroller seit immer IN BASIC, und bin gut
> gefahren. Dass man für jedes simple I2C-Device eine Bibliothek braucht,
> ist Arduino - mässige Inkompetenz.
Dann schreib mal eine USB-Ansteuerung oder TCP/IP-Stack selbst :-)

von Karl K. (karl2go)


Lesenswert?

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.

von mmm (Gast)


Lesenswert?

Christian M. schrieb:
>>> Void()
>> Was ist das, hab ich noch nie gesehen?
>
> Also noch nie C gesehen...

Nenn' doch mal ein beispiel für void().

void(variable); kann man machen, um "unused argument" Warnungen 
loszuwerden, aber void()?

von Bernd K. (prof7bit)


Lesenswert?

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.

von Dr. Sommer (Gast)


Lesenswert?

Vielleicht sollte der TO mal Python oder Ruby ausprobieren. Diese 
Sprachen erfüllen zwar überhaupt nicht die Anforderungen, sind aber sehr 
leicht zu erlernen und führen schnell zu Erfolgserlebnissen. Man muss 
sich nicht mit so vielen fiesen Details wie in C herumschlagen, aber 
dennoch nicht auf eine gute Sprachstruktur verzichten. Vielleicht 
erkennt er so, dass die Anforderungen nicht besonders sinnvoll sind und 
er lediglich von der C-Lernkurve geschädigt ist. Wenn man mithilfe 
dieser Sprachen grundlegende Sprachelemente gut verstanden hat, kann man 
immer noch zu C, Pascal, whatever wechseln. Tatsächlich läuft aber 
Python sogar teilweise auf Mikrocontrollern, oder auch auf dem R-PI.

Beitrag #5531032 wurde vom Autor gelöscht.
von P.Loetmichel (Gast)


Lesenswert?

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

Ada Programmierer sitzen in den Bundeswehrkantinen rum!

von Peter D. (peda)


Lesenswert?

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
}

von HildeK (Gast)


Lesenswert?

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

Mag sein.
Aber wenn jemand, wie der TO, fast bei Null anfängt, dann kann ihm ein 
µC-Forum sehr viel helfen. Und z.B. hier gibt es nun mal viele, die C 
oder Assembler beherrschen.

A-Freak schrieb:
> Alles was so mit "Pointer",
braucht man zu Beginn und für einfache Lernprogramme nicht unbedingt.

> "Casten",
ebenso. Definiere die Variablen sinnvoll und 'casten' fällt (fast immer) 
weg

> "Void()",
siehe oben die anderen Posts. Oder meintest du "int main(void)?

>"=" versus "==",
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?

> Klammer-Konstruktionen
Wenn du die Prios der Operatoren kennst, dann brauchst du wenig 
Klammern. Wenn du nicht jedes mal darüber nachdenken willst, dann setze 
die Klammern und mach es für dich so übersichtlich wie möglich. Auch in 
der Schule hat man Klammer gebraucht, um die Priorisierung der Punkt- 
und Strichrechnung zu ändern.

> und so Zeugs mir zu abstrakt,
Naja, ohne Lernbereitschaft gewisser Grundlagen zu einer Sprache wirst 
du in jeder erfolglos bleiben. Besorge dir ein gutes Buch und 
beschäftige dich mal ein paar Tage damit.

von Volker S. (vloki)


Lesenswert?

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 ;-)

von Stefan F. (Gast)


Lesenswert?

> Welche Programmiersprache soll ich lernen?

Das ist ja mal eine neue Frage. Hatten wir schon lange nicht mehr :-)

Da du ATtiny Mikrocontroller programmieren willst, gibt es meiner 
Meinung nach nur eine sinnvolle Antwort: C

Weil:
> C hat den entscheidenden Vorteil, dass es für alle Plattformen
> verfügbar ist.

Da du C ausgeschlossen hast wäre der Plan B: Bascom

Aber:
> Vergiss die Nischenprodukte wie Bascom. Sobald du die
> Plattform wechselst, steht es nicht mehr zur Verfügung und
> du mußt etwas neues lernen.

Ich zitiere die Kollegen hier, weil ich der gleichen Meinung bin.

von Philipp G. (geiserp01)


Lesenswert?

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.

: Bearbeitet durch User
von Stefan F. (Gast)


Lesenswert?

> 90 % aller Profis programmieren in BASCOM!

Echt? Wie kommst du auf die 90%?

von ACDC (Gast)


Lesenswert?

Philipp G. schrieb:
> //C
> int i = 0;
> for (i = 0; i < 11; i++)
> {
>   SetLEDValue(i);
> }

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

von Philipp G. (geiserp01)


Lesenswert?

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.

von Dr. Sommer (Gast)


Lesenswert?

1
for (int_least8_t i = 0; i < 11; ++i) {
2
  led [i].set (1);
1
for (auto& l : led)
2
  led.set (1);

Beitrag #5531110 wurde von einem Moderator gelöscht.
von старший мудрый троль (Gast)


Lesenswert?

Lass den Tiny, der ist Murks fuer Sparer. Geeignet fuer sehr hohe 
Stueckzahlen, wenn es um cents geht.
Aber fuer kleine Stueckzahlen nimmt man besser etwas grosszuegiger 
ausgestattetet Controller, zB etwas wie einen Mega644, oder so.

von Zille (Gast)


Lesenswert?

Peter D. schrieb:
> 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.

Trotz der geringen Anzahl an unterschiedlichen Befehlen ist der 
Assembler-Befehlssatz alles andere als eingeschränkt (der ATTiny 
schneidet in dieser Hinsicht schlechter ab, z.B. wegen dem fehlendem 
Multiplikationsbefehl).

Für die Bankumschaltungen bei den Variablenaufrufe gibt es auch in 
Assembler Möglichkeiten, um daraus resultierende Fehler zu minimieren 
(bzw. ganz zu vermeiden).

Die aktuellen PICs haben für den Code i.A. nur eine Page, somit gibt es 
den "Codepageüberlauf" nur, wenn Du mehr Code hast als in den Controller 
hineinpasst. Dieses Problem hat aber, ohne Ausnahme, jeder Controller.

von Zuzel (Gast)


Lesenswert?

Hallo

C bzw. C++ oder auch "etwas schöner gemacht" wie im Arduino Universum 
ist im 8Bit µC Bereich schon die richtige Programmiersprache.

Die praktische Anwendung und das erlernen sind gar nicht so kompliziert 
wenn, und das ist extrem wichtig und oft der Knackpunkt, die Bücher und 
Tutorials gut erklären und sinnvoll aufgebaut sind.
Leider driften viele Autoren sehr schnell in ihre "Fachsprache" ab, 
wobei  das jetzt nicht so auffällig sein muss das man es als "Wissender" 
direkt bemerkt, oft handelt es sich um vorgebliche 
Selbstverständlichkeiten für jemanden der in der Materie drin steckt die 
es aber für den lernwilligen Laien bei weiten nicht sind - nicht jeder 
hat ein Abitur oder hat mal ein Studiengang (schon gar nicht im 
technisch - mathematischen oder Informatik Bereich)absolviert.

Was ist z.B. eine Funktion kann sehr gut verständlich und vor allem 
Praxistauglich erklärt werden, aber leider auch durch abstrakte und 
"versteckte" Fachsprache absolut unverständlich für einen Anfänger sein.
Werden dann in diesen Beispiel noch die Begriffe Funktion und Methode 
lustig gemischt versteht man schnell gar nichts mehr und das lernen wird 
unnötiger
Weise erschwert.
Gerade der gut abgegrenzte 8Bit µC Bereich bietet eigentlich gute 
Chancen eine Programmiersprache wie C Praxisnah und ohne(!) starke 
Abstraktion und die sonst notwendige Verallgemeinerung (die Sprache soll 
sonst immer ja auf jeden System funktionieren) den Lerneilligen bei zu 
bringen, auch kann in solch einen abgegrenzten Bereich auf "Schwierige" 
Bestandteile der Sprache verzichtet werden die im 8Bit µC Bereich 
sowieso nie, oder nur äußerst selten gebraucht werden.
Ein (viele) gute Bücher und Tutorials von Autoren die sich in Anfänger 
hineindenken können und die sehr genau drauf achten wann und wie 
Fachsprache (und hierzu zähle ich nicht nur die klar erkennbare 
Fachsprache) eingesetzt wird sind absolut entscheiden das eine Sprache 
passend für den Einsitzbereich frust frei und mit freude erlernt werden 
kann.
Im von vielen "Profis" hier so verschmähte Arduinouniversum wird gezeigt 
wie es funktionieren kann - wobei es bei den Büchern dort leider auch 
sehr viel Oberflächlichen Mist gibt und die Autoren wenn es mal etwas 
tiefgreifender zugeht viel zu oft auch  in die "Fachsprachenfalle" 
treten bzw. einfachste Hardware Grundlagen die in nahezu lächerliche 
"Babysprache" vermittelt wird mit für den Anfänger viel zu 
anspruchsvollen Programmierbeispielen und undurchschaubaren Erklärungen 
vermischt werden.
Aber im Gegensatz zu sonstigen allgemeinen Literatur zu 
Programmiersprachen wie C und/oder µC Hardware und Anwendungs Bereich 
gibt es wenigsten manchmal was nützliches - allerdings nie in einen Buch 
oder Tutorial und ein 100 oder auch 200 Seiten Arduino Buch kann man 
eigentlich direkt liegen lassen wenn man richtig die "Sprache" (ist je 
nicht wirklich eine eigene Sprache) lernen will.

So jetzt werden viele sagen: So lernt man aber keine Programmiersprache 
wie C wirklich richtig.

Da gebe ich euch durch aus recht - aber wenn man eine Sprache wie C nur 
in einen festgelegt Umfeld wie den 8BiT µC anwenden will reicht das mehr 
als aus  in besonders wenn dafür mehr und praktisch relevant auf die 
Besonderheiten und "Fallen" in so einen speziellen Umfeld eingegangen 
wird.

Zuzel

von M.A. S. (mse2)


Lesenswert?

(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 }.

: Bearbeitet durch User
von Walter K. (walter_k488)


Lesenswert?

Du könntest Forth lernen ...

von Mark B. (markbrandis)


Lesenswert?

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

von Joachim S. (oyo)


Lesenswert?

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...

von M.A. S. (mse2)


Lesenswert?

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.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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...

von Stefan F. (Gast)


Lesenswert?

Da ich noch auf Lochraster löte, sind für mich einige ATtiny Modelle 
durchaus interessant. Ich habe mit einen üppigen Vorrat an ATtiny13 
zugelegt - würde heute allerdings eher auf ATtiny85 setzen. Diese sind 
schön klein und ersetzen leicht eine sonst aufwändigere Logik- oder 
Timer-Schaltung.

Der nächst größere, den ich benutze, ist dann aber schon der ATmega328, 
meist in Form eines Arduino Nano Klons.

Ob man für Vergleich und Zuweisung einen oder zwei Operatoren hat, ist 
erfahrenen Programmierern ziemlich egal. Wer über solche Details 
diskutiert, hat wohl keine echten Herausforderungen zu meistern.

von HildeK (Gast)


Lesenswert?

Lothar M. schrieb:
> In VHDL ist ein <= mal eine Zuweisung und mal ein Vergleich.

Ich hatte befürchtet, dass es Ausnahmen gibt. :-)
Und hätte noch dazu schreiben können, dass man aus dem Kontext schon 
unterscheiden könnte. Bleibt die Frage, was sinnvoller bzw. weniger 
fehlerträchtig ist.
Es schränkt jedenfalls gewisse Freiheiten ein, vielleicht wäre das 
manchmal auch von Vorteil. Fast jedem ist es schon passiert, dass man 
einen Vergleich wollte und eine Zuweisung schrieb - und dann gesucht hat 
...

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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... ;-)

von Bernd D. (Firma: ☣ ⍵ ☣) (bernd_d56) Benutzerseite


Lesenswert?

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

von M.A. S. (mse2)


Lesenswert?

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)?

von Bernd D. (Firma: ☣ ⍵ ☣) (bernd_d56) Benutzerseite


Lesenswert?

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

von Einer K. (Gast)


Lesenswert?

A-Freak schrieb:
> "C" und verwandte Sprachen muß ich ausschließen.
Das halte ich auch für einen Irrtum.

OK, ich war nie ein C Freund, habe aber in tiefer Vergangenheit die  C 
Grundlagen lernen können/dürfen. (SCO Unix)

Bin seit ca 3 Jahren voll auf Arduino, und damit auf C++.
3 Jahre, intensives Hobby, und habe noch längst nicht alle Tiefen 
ausgelotet.

Ich schätze mal, dass man insgesamt ca 10 Jahre braucht, um in C++ recht 
Sattelfest zu werden.

PS:
Die C++ Syntax/Sprachdefinition, hat man in 3 Monaten drauf.

von Patrick B. (p51d)


Lesenswert?

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.

: Bearbeitet durch User
von M.A. S. (mse2)


Lesenswert?

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

Danke für die Info. :)

von M.A. S. (mse2)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

Karl K. schrieb:
> 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.

Anstatt zu motzen wäre es wohl besser, hier mal einen wirklich guten und 
für bare-metal geeigneten Pascal-Compiler zu benennen.

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. Das ist das eigentliche Problem.

Und es soll mir keiner sagen, daß C da irgendwelche sprachlichen 
Vorteile hätte, die hat es nämlich nicht. Der einzige Grund, weswegen 
heutzutage C quasi ubiquitär ist, besteht darin, daß es dafür gute 
Compiler gibt.

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.

W.S.

von (prx) A. K. (prx)


Lesenswert?

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

von M.A. S. (mse2)


Lesenswert?

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?

Beitrag #5531569 wurde von einem Moderator gelöscht.
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

von M.A. S. (mse2)


Lesenswert?

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!  ;)

: Bearbeitet durch User
Beitrag #5531581 wurde von einem Moderator gelöscht.
Beitrag #5531587 wurde von einem Moderator gelöscht.
von M.A. S. (mse2)


Lesenswert?

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...

: Bearbeitet durch User
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

von Bernd D. (Firma: ☣ ⍵ ☣) (bernd_d56) Benutzerseite


Lesenswert?

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

von il Conte (Gast)


Lesenswert?

ich weiß nicht wir ihr das seht, ich
halte den TO für einen Edel-Troll.

Der sondert hier ein einziges Mal sein 'Duftmarke' ab
und meldet sich dan anschließend nicht mehr :-( bis jetzt)

(der Thread hat mittlerweile schon 68 Einträge)

A-Freak schrieb:
> da habe schon mehrfach erfolglos versucht
> mir sowas in das Hirn zu prügeln

A-Freak schrieb:
> Ansonsten sind mir grundlegende
> Algorithmen und Abläufe sehr gut bekannt.

Das passt irgendwie nicht zusammen
(einmal IQ=0 das andere Mal IQ=100 :-)

Beitrag #5531615 wurde von einem Moderator gelöscht.
Beitrag #5531616 wurde von einem Moderator gelöscht.
Beitrag #5531619 wurde von einem Moderator gelöscht.
von Bernd D. (Firma: ☣ ⍵ ☣) (bernd_d56) Benutzerseite


Lesenswert?

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

von Egon D. (Gast)


Lesenswert?

Frank M. schrieb:

> Pascal ist nicht vernachlässigt worden, sondern Pascal
> ist tot.

...und Klämpfl und van Canneyt sind die Chefpathologen,
oder wie?!

Beitrag #5531626 wurde von einem Moderator gelöscht.
Beitrag #5531628 wurde von einem Moderator gelöscht.
Beitrag #5531629 wurde von einem Moderator gelöscht.
Beitrag #5531630 wurde von einem Moderator gelöscht.
von Egon D. (Gast)


Lesenswert?

il Conte schrieb:

> ich weiß nicht wir ihr das seht, ich halte den TO
> für einen Edel-Troll.

Ja -- und?

Ich hatte das hier bis jetzt immer für ein Diskussion-
forum gehalten: Über interessante Themen wird diskutiert,
und von uninteressanten Themen hält man sich fern.

Beitrag #5531632 wurde von einem Moderator gelöscht.
Beitrag #5531633 wurde von einem Moderator gelöscht.
von Egon D. (Gast)


Lesenswert?

Frank M. schrieb:

> Trotzdem wird sich auf dem µC-Sektor in absehbarer Zeit
> nicht viel tun, C/C++ also als Standard bestehen bleiben.

Was ich ehrlich nicht verstehe, das ist, wieso nicht jemand
dahergeht und C als Zwischensprache verwendet. Man könnte
alle Systeme programmieren, für die es einen C-Compiler
gibt (also ungefähr alle), müsste sich aber nicht mit dem
Gepointere und ähnlichem Zeug herumärgern...

Beitrag #5531641 wurde von einem Moderator gelöscht.
Beitrag #5531642 wurde von einem Moderator gelöscht.
Beitrag #5531643 wurde von einem Moderator gelöscht.
Beitrag #5531644 wurde von einem Moderator gelöscht.
Beitrag #5531646 wurde von einem Moderator gelöscht.
Beitrag #5531648 wurde von einem Moderator gelöscht.
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

Beitrag #5531651 wurde von einem Moderator gelöscht.
von Peter M. (r2d3)


Lesenswert?

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

Beitrag #5531655 wurde von einem Moderator gelöscht.
Beitrag #5531656 wurde von einem Moderator gelöscht.
Beitrag #5531657 wurde von einem Moderator gelöscht.
Beitrag #5531658 wurde von einem Moderator gelöscht.
von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

von M.A. S. (mse2)


Lesenswert?

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

von Peter K. (Firma: www.pic-microcontroller.de) (peter_k)


Lesenswert?

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.

von Peter M. (r2d3)


Lesenswert?

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.

von Egon D. (Gast)


Lesenswert?

M.A. S. schrieb:

> 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.

Klar -- aber mir ist kein freies Werkzeug bekannt, das
sich auch für kleinere Maschinen eignet.

Es scheint die Überzeugung vorzuherrschen, dass komplexe
Sachverhalte sowieso NUR von Leuten programmiert werden,
die C++ beherrschen und anwenden wollen -- was ich für
grundfalsch halte.

Eher verwendet man Pascal mit eingebettetem Assembler,
als irgendwas Neues mit eingebettetem C einzusetzen.

Beitrag #5531699 wurde von einem Moderator gelöscht.
Beitrag #5531732 wurde von einem Moderator gelöscht.
Beitrag #5531746 wurde von einem Moderator gelöscht.
Beitrag #5531748 wurde von einem Moderator gelöscht.
von Stefan F. (Gast)


Lesenswert?

Es kommt nicht nur auf die Fachliche Information an, sondern auch auf 
die Art, wie man sie überbringt.

Wenn ich schreibe: "Ey du dummer Eber, du hast + mit - verwechselt", 
dann wird das zu Recht gelöscht.

Beitrag #5531767 wurde von einem Moderator gelöscht.
von Frank D. (Firma: Spezialeinheit) (feuerstein7)


Lesenswert?

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.

von Rolf M. (rmagnus)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

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.

von A-Freak (Gast)


Lesenswert?

@Karl2go:

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

@Geiserp01:

#VB
Dim i as Integer
for i = 0 to 10
   SetLEDValue(i)
next


//C
int i = 0;
for (i = 0; i < 11; i++)
{
  SetLEDValue(i);
}

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


@Barrex:

Ausschließlich privat.

Daher, und weil ich doch schon älter bin, habe ich nicht mehr den Kopf 
daß daß ich diese abstrakten Sprachbeispiele wie oben wie oben noch 
wirklich auswendig lernen kann.

Vor allem eben dieses "=" versus "==" kommt mir total falsch vor weil 
ich eben so denke:

IF Schalterstellung = 3 THEN
  ...
END



Ich muß auch offen zugeben daß ich nicht Programmieren an sich als 
Tätigkeit lernen will, sondern das nur als notwendigen Teil von 
gemischten Projekten. Zum Beispiel ein Bedienteil für einen 
Kurzwellenempfänger der mit DDS statt Kapazitätsioden-VFO abgestimtm 
wird. Oder ein Akkuladegerät bei dem die Ablaufsteuerung nicht in 12 
Logikgattern steckt sndern in einem uC. Oder eine Spulenwickelmaschine.


@Vloki:

@il_conte:

Wenn du im Forum nach meinem Benutzernamen suchst wirst du sehen daß ich 
doch schon ein paar Jahre länger dabei bin und wo meine Fachgebiete 
liegen zu denen ich konstruktiv beitrage. Danach kannst du gerne noch 
einmal entscheiden ob du mich weiter Troll bezeichnen möchtest.

> Der sondert hier ein einziges Mal sein 'Duftmarke' ab
und meldet sich dan anschließend nicht mehr :-( bis jetzt)

Da ich auch noch anderes in der realen physikalischen Welt zu tun habe 
bin ich nicht stündlich online in Foren unterwegs.



@Bernd_D56:

> 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.


@rmnagnus:

Die neueren Tinys haben jetzt auch einen Mul-Befehl z.B. der 817

@peda:

Exakt so

Also z.B. Spannung vom NTC einlesen und PWM für dne Lüfter hochfahren 
währen für mich schon Signalverarbeitung wie ich sie ich bisher halt mit 
TLC393 gemacht habe.




@All:

Danke für die paar hilfreichen Kommentare, ganz besonders noch einmal zu 
dem super interresantem GQBasic

von Peter D. (peda)


Lesenswert?

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();

: Bearbeitet durch User
von Ralf H. (hilti68)


Lesenswert?

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.

von Dirk K. (merciless)


Lesenswert?

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

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

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...

von M.A. S. (mse2)


Lesenswert?

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!

von M.A. S. (mse2)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

Den Unterschied zwischen = und == musst Du Dir bei C nicht merken. Der 
Compiler weist Dich ggf. schon darauf hin, wenn du alle Warnungen 
eingeschaltet hast (gcc Parameter -Wall). Die meisten 
Entwicklungsumgebungen (außer Arduino) tun das auch schon direkt im 
Editor.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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 :-)

von M.A. S. (mse2)


Lesenswert?

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.

von Adam P. (adamap)


Lesenswert?

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.

: Bearbeitet durch User
von Stefan F. (Gast)


Lesenswert?

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.

Ziel: Kleiner, schneller, besser.

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.

Ganz markant finde ich, dass bei neuen Sprachen und Frameworks permanent 
Performance-Verbesserungen beworben werden. Und doch sind sie allesamt 
immer noch langsamer als das gute alte C. Ich habe das Gefühl, sie lösen 
primär Probleme, die sie sich vorher selbst eingebrockt haben - und zwar 
bei dem Versuch, das Programmieren zu vereinfachen.

von Volker S. (vloki)


Lesenswert?

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 ;-)

: Bearbeitet durch User
von M.A. S. (mse2)


Lesenswert?

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.

von Ralf H. (hilti68)


Lesenswert?

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 ;)

von M.A. S. (mse2)


Lesenswert?

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.

von Einer K. (Gast)


Lesenswert?

Stefanus F. schrieb:
> dass bei neuen Sprachen und Frameworks permanent
> Performance-Verbesserungen beworben werden

Es gibt verschiedenste Formen von "Performance".

z.B. für mich ist selten das letzte Zehntel bei den Rundenzeiten 
wichtig.
Insbesondere bei dem Laufzeitverhalten der Anwendung.
Auch Speicherverbrauch ist mir nahezu egal, solange es rein passt.

Ich lege meist eher wert auf
-Schnelle Entwicklung
-Wartbarkeit
-Portabilität


---

Dieses Great Cow BASIC habe ich mir in der Vergangenheit mal angesehen.
Nix für mich. Passt nicht gut in/an meine Denke.
Wobei ich zugeben muss, dass es sowohl lernbar, als auch funktionsfähig 
ist.

von M.A. S. (mse2)


Lesenswert?

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.

: Bearbeitet durch User
von Ralf H. (hilti68)


Lesenswert?

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 ;)

von Stefan F. (Gast)


Lesenswert?

Allerdings. Meinen ersten 8051 Assembler hatte ich mir sogar selbst in 
Pascal geschrieben. Es gab halt nichts anderes (bezahlbar).

Und das Pascal Paket kostete mehrere hundert DM, das war damals etwas 
mehr als ein halbes Azubi-Monatsgehalt.

von Mr. K. (kaktus-)


Angehängte Dateien:

Lesenswert?

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

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

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?

von Stefan F. (Gast)


Lesenswert?

> Warum hat man das bei einer neuen sauberen Sprache übernommen?

Weil das irgend jemand haben wollte. Auch in Java wurden nachträglich 
zahlreiche Konstrukte anderer Sprachen übernommen, die als 
fehlerträchtig gelten. Dabei sollte Java gerade damit aufräumen.

Wie ich schon sagte, jede Sprache verkommt irgendwann. Die 
ursprünglichen Ziele gelten nicht mehr. Man fragt sich zu Recht, wofür 
wir denn so viele prinzipiell gleichwertige Programmiersprachen 
brauchen.

Die Oldies kehren dann wieder zu den alten Klassikern zurück, die sie am 
Besten beherrschen. Die wurden ebenfalls weiter entwickelt und können 
daher prinzipiell auch alles irgendwie.

von Cyblord -. (cyblord)


Lesenswert?

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.

von M.A. S. (mse2)


Lesenswert?

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.

von Mr. K. (kaktus-)


Lesenswert?

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

von Ralf H. (hilti68)


Lesenswert?

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 ;)

von M.A. S. (mse2)


Lesenswert?

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).

von M.A. S. (mse2)


Lesenswert?

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.

von Karl K. (karl2go)


Lesenswert?

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.

von Volker S. (vloki)


Lesenswert?

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

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

von Karl K. (karl2go)


Lesenswert?

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.

von M.A. S. (mse2)


Lesenswert?

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)?

von Karl K. (karl2go)


Lesenswert?

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.

von M.A. S. (mse2)


Lesenswert?

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.

von Karl K. (karl2go)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

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.

von Egon D. (Gast)


Lesenswert?

Stefanus F. schrieb:

> Wie ich schon sagte, jede Sprache verkommt irgendwann.
> Die ursprünglichen Ziele gelten nicht mehr. Man fragt
> sich zu Recht, wofür wir denn so viele prinzipiell
> gleichwertige Programmiersprachen brauchen.

Braucht man nicht.

Das Problem ist: Man kann deren Entstehung nicht wirksam
verhindern.

Schöpfer von Programmiersprachen haben (notwendigerweise)
von Compilerbau deutlich mehr Ahnung als der Durchschnitts-
programmierer. In Kombination mit dem stets vorhandenen
Spieltrieb (=Drang zum Overengineering) bewirkt das, dass
jede Sprache ein Unzahl neuer (Fehler-)Möglichkeiten
bietet -- aber nur ein kleiner Teil der neuen bzw. veränderten
Eigenschaften ist wirklich sinnvoll. WELCHER Teil das ist,
weiss man aber immer erst hinterher :)

von Stefan F. (Gast)


Lesenswert?

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

Allerdings schätze ich, dass der Fortschritt noch weiter in diese 
Richtung gehen wird. Während in den 90er Jahren die bare-metal 
Grundlagen noch hilfreich waren, um einen guten Job zu machen, muss man 
heute eher damit klar kommen, sie eben nicht zu beherrschen.

Im Enterprise Umfeld (nicht µC) kommt man gar nicht mehr umhin, 
Libraries und Frameworks zu verwenden, deren Funktionsweise völlig 
unklar ist. Man muss allerdings imstande sein, anhand der verfügbaren 
Doku herauszufinden, wie man sie korrekt verwendet. So wie man auch Auto 
fahren können muss, ohne einen blassen Schimmer von der Funktionsweise 
des Motors zu haben.

Die Mikrocontroller wird dieses Schicksal hoffentlich erst nach meinem 
Ableben betreffen. Ich interessiere mich für µC und Elektronik nämlich 
gerade deswegen, weil ich mich dort noch mit Grundlagen beschäftigen 
kann. Das ist für mich ein netter und hilfreicher Ausgleich zum Job als 
Java Enterprise Programmierer. Die Grundlagen geben mir ein Gefühl von 
Sicherheit, welche ich im Job vermisse.

von Roland F. (rhf)


Lesenswert?

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

von Heinz B. (Firma: Privat) (hbrill)


Lesenswert?

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.

von A. S. (Gast)


Lesenswert?

Ralf H. schrieb:
> Früher hatte man kaum eine Wahl.

Im Sinne von "für diese HW".

Insgesamt aber ist die Anzahl der Programmiersprachen wohl schon solange 
etwa 2000, wie das Öl noch 40 Jahre reicht.

von Karl K. (karl2go)


Lesenswert?

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.

von M.A. S. (mse2)


Lesenswert?

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.

: Bearbeitet durch User
von Karl K. (karl2go)


Lesenswert?

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.

von Egon D. (Gast)


Lesenswert?

M.A. S. schrieb:

> Zwar würde ich nicht zu etwas anderem wechseln, wenn
> dieses andere nicht große Vorteile hätte,

Was wäre denn ein hinreichend großer Vorteil, um zu
wechseln?

von M.A. S. (mse2)


Lesenswert?

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.

von Jörg (zwischenfrequenz)


Lesenswert?

Hallo A-Freak,

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

von M.A. S. (mse2)


Lesenswert?

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.  ;)

: Bearbeitet durch User
von Volker S. (vloki)


Lesenswert?

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

von (prx) A. K. (prx)


Lesenswert?

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

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

von M.A. S. (mse2)


Lesenswert?

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).

von Volker S. (vloki)


Angehängte Dateien:

Lesenswert?

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...

: Bearbeitet durch User
von Stefan F. (Gast)


Lesenswert?

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

von M.A. S. (mse2)


Lesenswert?

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.

: Bearbeitet durch User
von Volker S. (vloki)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.“

von Karl K. (karl2go)


Lesenswert?

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".

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Roland F. (rhf)


Lesenswert?

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

von Roland F. (rhf)


Lesenswert?

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

von Egon D. (Gast)


Lesenswert?

Roland F. schrieb:

>> 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.

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

von Peter M. (barrelshifter)


Lesenswert?

Ein recht gutes Basic, vor allem kostenlos, ist Great Cow Basic.
Ist auf die AVRs abgestimmt.
Einfach mal anschauen.

Beitrag #5533363 wurde von einem Moderator gelöscht.
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Vincent H. (vinci)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Vincent H. (vinci)


Lesenswert?

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.

: Bearbeitet durch User
von Einer K. (Gast)


Lesenswert?

Was erwartest du?

Ein Diskussion über Computersprachen, hat immer mit persönlichen 
Vorlieben zu tun. Und mit Sachzwängen.

Sobald sich Vorlieben unterscheiden, ist der Startimpuls für 
Grabenkriege und Eskalationsspiralen gesetzt.

Ganz normal....
Dumm, völlig dumm, aber normal.

von Karl K. (karl2go)


Lesenswert?

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.

von Vincent H. (vinci)


Lesenswert?

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"...

von Peter M. (r2d3)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

von Bernd D. (Firma: ☣ ⍵ ☣) (bernd_d56) Benutzerseite


Lesenswert?

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.

von Egon D. (Gast)


Lesenswert?

Karl K. schrieb:

> 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.

Mag ja sein.

Bei der testweisen Nutzung von FreePascal in einem Projekt
habe ich den Eindruck gewonnen, dass die offizielle Projekt-
dokumentation schlecht strukturiert ist und man über die
Aktualität im Zweifel gelassen wird.

Das ist auch kein Vorwurf, sondern eine rein sachliche
Feststellung, denn die Schwierigkeiten müssen rein aufgrund
der schieren Größe des Projektes beträchtlich sein. Es ist
mir völlig logisch, dass Programmierer lieber programmieren
als die Dokumentation zu pflegen.
Van Canneyt tut da einiges, aber die Ergebnisse würde ich
als durchwachsen bezeichnen.


> Allerdings erstellen diese Leute dann eher eigene und
> kapern nicht andere und noch dazu anderssprachige Einträge.

Du hast eine merkwürdige Art, Dir die Welt so zu machen, wie
sie Dir gefällt.

Von offizieller Projektdokumentation erwarte ich, dass die
Dokumente bei Bedarf aktualisiert (und die alten gut zugänglich
archiviert) werden. Nennst Du das "kapern"?
Von jeder Art Dokumentation (offizieller wie privater)
erwarte ich, dass eindeutig klar wird, auf welchen Stand der
Software, welche Compilerversion etc. sie sich bezieht.

von Egon D. (Gast)


Lesenswert?

Vincent H. schrieb:

> 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.

Du übersiehst das Kernproblem.

Diejenigen, die mehrere Programmiersprachen so beherrschen,
dass sie fundierte Aussagen darüber machen können, haben
in der Regel einen beträchtlichen theoretischen und
empirischen Wissenshintergrund, was die Programmiersprachen
angeht. Häufig interessieren sie sich für den Computer als
Ding an sich, als Gegenstand der Forschung.

Die Proteste kommen von den Leuten, die im Computer ein
Hilfsmittel sehen, das sie lediglich sach- und fachgerecht
verwenden wollen. Für diese Leute -- zu denen ich mich auch
zähle -- ist nicht einzusehen, wieso man eine geradezu
babylonische Sprachverwirrung schaffen muss, um genau
dieselben Probleme wie vor 30 oder 50 Jahren auf immer
wieder andere, aber stets kompliziertere Weise als früher
zu lösen.

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.

von (prx) A. K. (prx)


Lesenswert?

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.

von Egon D. (Gast)


Lesenswert?

A. K. schrieb:

> 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.

Klar -- aber das erklärt nicht, warum man (=ich) bei neuen
Sprachen häufig den Eindruck hat, sie würfen genau DAS
über den Haufen, was an den alten Sprachen gut war, und
fügten komplizierten neuen Krempel hinzu, den nur Informatik-
Studenten für den "obfuscation contest" brauchen.

von Stefan F. (Gast)


Lesenswert?

Es gibt immer wieder jemanden, der für seinen aktuellen Anwendungsfall 
eine spezialisierte Programmiersprache (oder ein Framework) erfindet. So 
mag es gelingen, die Programmierung einfacher Roboter (Linienverfolger 
und so) mit seiner neuen Sprache sogar 8 jährigen Kindern verständlich 
zu machen.

Dann dreht er die große Werbetrommel, was dazu führt, dass auch 
Erwachsene diese neue Programmiersprache ernsthaft einsetzen wollen. 
Plötzlich stellt sich heraus, dass die Abfrage einfacher Schalter, 
Distanz-Sensoren und das Steuern von zwei Antriebsmotoren nicht genügt. 
Man will auch Internet Kommunikation vereinfachen. Und schwupps, wächst 
das Paket auf die zehnfache Größe an.

Der Nächste will ein grafisches Touch-Screen Display benutzen. Da Grafik 
ursprünglich gar nicht vorgesehen war, kommt ein großer Balkon aus 
Libraries an die neue Programmiersprache. Natürlich zu nichts bekanntem 
kompatibel - es soll ja nach wie vor auf irgendwie auf den 
ursprünglichen kleinen µC laufen, die immer noch im diversen Baukästen 
im Handel sind.

Und so kommt es, dass die neue elegante kompakte einfache 
Programmiersprache all dies nicht mehr ist.

Schaut euch doch mal die großen aktuellen Sprachen an. Die Unterschiede 
zwischen C++, Java und .NET sind meiner Meinung nach verschwindend 
gering. Wer mehr Sprachen kennt kann dieser Liste sicher noch einige 
andere hinzufügen.

Am Ende der Entwicklungsphase (>20 Jahre) kann jede Sprache fast alles 
fast gleich. Es sei denn, sie bleibt ihrer ursprünglichen 
Spezialisierung treu.

von Karl K. (karl2go)


Lesenswert?

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.

von Egon D. (Gast)


Lesenswert?

Karl K. schrieb:

> 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?

Ja, das habe ich.

Und -- nein, ich gehe nicht weiter auf Dein Gestänkere ein.
Auf dieses "Niveau" lasse ich mich nicht herabziehen.

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 für neue bzw. sporadische Nutzer der
Software ziemlich ärgerlich.

Wenn Du eine nüchterne und sachliche Tatsachenfeststellung
immer als Anlass zum Rumgepisse nehmen musst, dann ist das
eben so. Ich bin IPx5 (strahlwasserfest).


> 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.

Siehst Du, und ich eben nicht.

Ich bin Debian-User; Debian hängt bekanntermaßen oft ziemlich
hinterher. Es hat teilweise erheblicher Sucherei in der Online-
Doku bedurft, um herauszufinden, welche Aussage denn nun für
MEINE Compilerversion zutreffend ist.

von Karl K. (karl2go)


Lesenswert?

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.

von Egon D. (Gast)


Lesenswert?

Karl K. schrieb:

> 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?

Siehst Du, genau das ist der Grund, warum Diskussionen
mit Dir so nervtötend sind: Ich habe immer das ungute
Gefühl, Du drehst mir die Argumente absichtlich im Mund
herum.

Nein, es ist natürlich nicht die Schuld der FreePascal-Leute,
dass die Debian-Pakete hinterherhängen -- es ist die Schuld
der FreePascal-Leute, dass aus deren Dokumentation nicht
eindeutig hervorgeht, für welche Compilerversion sie gilt.

War das wirklich so schwer zu verstehen?


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

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


> 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.

Nein -- aber es zeigt sich dort in besonderer Schärfe.

Bei kommerziellen Auftragsentwicklungen steigt Dir der
Kunde schon auf's Dach, wenn die Doku zwar Vertrags-
bestandteil war, aber von Dir nicht geliefert wird.

Bei FOSS wird halt keine Dok geschrieben, wenn keiner
Lust dazu hat.


> 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.

Natürlich -- GUTE Dokumentation schreiben ist eine Kunst.

Aber um das Problem zu LÖSEN, muss man erstmal anerkennen,
dass es überhaupt ein Problem GIBT -- und nicht immer mit
"Wenn Du zu blöd bist, lass es einfach bleiben" kontern.

von Bernd K. (prof7bit)


Lesenswert?

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/

Beitrag #5534805 wurde vom Autor gelöscht.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.