Pascal und Ada für AVR

Svenja schrieb:
> Als alter Pascal Fan sehe ich gerade mit Freude das jemand das Thema Ada
> aufgenommen hat
> https://www.mikrocontroller.net/articles/AVR-Ada

Naja, den wesentlichen Inhalt der Seite hat Andreas selbst vor
etwa 8 Jahren beigetragen.  Viel steht ja eigentlich (leider) nicht
da, was ich durchaus auch als Zeichen geringer Publikumsresonanz
deuten würde.  Den nicht mehr funktionierenden Link auf die
Sourceforge-Seite hatte offenbar jahrelang keiner bemerkt. :~]

Das Projekt selbst hatte seinen letzten Release vor 4 Jahren, und
es ist mehr oder weniger eine One-Man-Show von Rolf Ebert.  Nicht,
dass ich eine solche kleinreden möchte (viele der Projekte, die ich
betreue, sind da auch nicht viel besser), aber mit der Hobbyarbeit
eines Einzelnen kann man erfahrungsgemäß keine großen Sprünge machen.

Stefan U. schrieb:
> Daher kann keine andere Sprache zuverlässiger sein.

Eine Sprache kann wohl per se gar nicht „zuverlässig“ sein.  Auch
Raketen, deren Steuerung in Ada geschrieben wurde, sind halt schon
verendet …

Aber C macht es dem Programmierer erfahrungsgemäß recht leicht,
auch scheunentorgroße Bugs in den Code zu bringen.  Kann gut sein,
dass Ada es einem da schon ein bischen schwerer macht.

Stefan U. schrieb:
>> Die Vorteile von Pascal und Ada sind halt nicht von der Hand zu
>> weisen wenn es um Zuverlässigkeit geht
>
> C ist 100% zuverlässig. Daher kann keine andere Sprache zuverlässiger
> sein.
>

Naja, die Frage ist aber, was kann "versehentlich" schief gehen. Und da 
macht es einem Ada schon (teilweise) ziemlich schwer.

Casts sind z.B. deutlich restriktiver (wenn man es nicht explizit 
erlaubt) und bekanntlich in C ein beliebter Aufhänger für Fehler.

> Nach meiner Einschätzung sind Pascal und ADA beides tote Pferde.

Sehe ich anders. Altium Designer (geschrieben in Delphi aka. 
Objektpascal) nur mal als ein Beispiel.

Ada wird oft da eingesetzt, wo es wirklich (!) kritisch ist.
Z.B. ATC (Air traffic control, insbesondere auch Luftraumüberwachtung 
ziviler Flugverkehr) oder Bahn (sowohl Streckenkontrolle als auch Züge). 
Die Steuerung des französische TGV ist afaik weitgehen in Ada 
programmiert.


> Im AVR Umfeld wird eigentlich nur mit C, Assembler, Bascom und ein bisschen C++ 
gearbeitet.

Ja. Da würde ich Ada auch eher selten sehen.

Für Cortexe (STM32) gibt es aber sogar Referenzimplementierungen des 
Runtime Systems, das in Ada ja deutlich umfassender ist als in z.B. C 
(u.A. multiple memory pools, harte Echtzeit usw.).

Also für "tot" sind die Pferde ganz schön munter^^

/regards

Jörg W. schrieb:
> Eine Sprache kann wohl per se gar nicht „zuverlässig“ sein.  Auch
> Raketen, deren Steuerung in Ada geschrieben wurde, sind halt schon
> verendet …

Meinst Du https://de.wikipedia.org/wiki/Ariane_V88 ?

DAS wäre aber mit jeder Sprache passiert.
Wenn Du ein "bewährtes" Modul ausd einem alten Design (das dort NIE an 
seine Limits gefahren werden konnte) wieder benutzt und dann ausserdem 
noch eine (jetzt) entstehen FP-Exceptio ignorierst, dann geht die SW 
halt auf "Panikdefault" (immerhin das) und muss letztendlich gesprengt 
werden.

Das kommt halt vom sparen an der falschen Stelle. In der Arianne 4 hat 
der Kram ja top funktioniert ;-)

/regards

Ich arbeite auch Pascal, resp Delphi, auf PC und mit E-Lab Pascal auf 
AVR. Fuer Microchip hab ich ein Pascal von Mikroelektronika.
Fuer laengerlebige Projekte ist Pascal geeigneter da wesentlich 
praxisnaeher und selbsterklaerender wie C.

Duck und weg.

Hi,
was man so alles in die armen 8-bitter quetschen will.
Wie wäre es mit Cobol?

Gruß
Andreas

Jörg W. schrieb:
> Eine Sprache kann wohl per se gar nicht „zuverlässig“ sein.

 Aber Parser und Compiler schon.

> Aber C macht es dem Programmierer erfahrungsgemäß recht leicht,
> auch scheunentorgroße Bugs in den Code zu bringen.

 Zumindest kann ich sicher sein, dass das meine Fehler sind und
 nicht Fehler beim parsen oder compilieren.

 Habe schon Fehler bei Wertzuweisungen, beim Vergleichen mit Konstanten,
 bei direktem inkrementieren oder dekrementieren eines Arrays, bei
 nested for-next mit do-while und viele andere erlebt.
 Ich mag zwar C nicht, aber (zumindest beim GCC) muss ich nicht uber
 Compiler und Parser nachdenken - wenn etwas nicht funktioniert, ist
 es mein Fehler.

 Und das ist der Nachteil von One-Man-Compiler - versteckte Fehler,
 die nur durch ausgiebiges testen zu entdecken sind - und dazu fehlt
 es ganz einfach an Benutzern.

Oh D. schrieb:
> Fuer laengerlebige Projekte ist Pascal geeigneter da wesentlich
> praxisnaeher und selbsterklaerender wie C

Nun ja, wie „längerlebig“ muss es denn sein?

Selbst 40 Jahre alten UNIX-Sourcecode kann man durchaus noch lesen.

Dass Ada außerhalb seiner Domäne wenig verbreitet ist, finde ich
durchaus etwas schade.  Eigentlich hätte es bei Mikrocontrollern
durchaus die Rolle einnehmen können, die C dort derzeit hat.

Andreas B. schrieb:
> was man so alles in die armen 8-bitter quetschen will.
> Wie wäre es mit Cobol?

Das gab es für 8080 mit Betriebssystem CP/M. Ebenso wie einen immer noch 
recht ordentlichen Subset von PL/I.

Ein ADA compiler muss zertifiziert werden, um den Namen tragen zu 
duerfen, und das ist aufwendig und teuer.

Nee. C ist eben nicht sicher. Wie schnell ist ein C=4 anstelle eines 
C==4 geschrieben. Der Compiler kann's nicht, weiss es nicht, und sagt 
mir nichts.

Es gibt eine Menge an schwierig zu findenden Bugs die in meinem Code 
auftreten koennen, weil der Compiler es eben zulaesst. Man kann mir 
vorwerfen fluechtig zu arbeiten. Ja. Moeglich

Marc V. schrieb:
> Und das ist der Nachteil von One-Man-Compiler

Der Compiler selbst ist ja nicht „One Man“, nur der Port für den AVR.

Der Rest des Compilers dürfte deutlich besser getestet sein, selbst
des Ada-Frontends.  Das Backend ohnehin.

Berny schrieb:
> Der Zielcode des Cobol-Compilersist nicht länger, als der entsprechende
> Zielcode eine C-Compilers.

Aber der Quellcode des Programms, der ist es schon. ;-)

Oh D. schrieb:
> Wie schnell ist ein C=4 anstelle eines C==4 geschrieben. Der Compiler
> kann's nicht, weiss es nicht, und sagt mir nichts.

Das ist nun gerade ein schlechtes Beispiel, welches in aktuellem
Sourcecode, der irgendwie was auf sich hält, nicht mehr vorkommen
wird.  Sämtliche Compiler warnen sowas seit vielen Jahren, sofern
man sie es warnen lässt und die Warnung natürlich sich zu Herzen
nimmt.

Aber es gibt genügend andere Dinge in C, die man schnell vergurken
kann.

Zumal man als vorsichtiger Programmierer 4=C schreibt. ;-)

A. K. schrieb:
> Zumal man als vorsichtiger Programmierer 4=C schreibt. ;-)

Finde ich k*cke zu lesen.  Schließlich fragt man ja im Leben auch
nicht: „Ist 10 gleich der Anzahl der Eier in der Packung?“

Seit Compiler diesen Fehler zuverlässig warnen, sehe ich für so eine
Verrenkung keinen wirklichen Grund mehr.

Jörg W. schrieb:
>> Zumal man als vorsichtiger Programmierer 4=C schreibt. ;-)
>
> Finde ich k*cke zu lesen.  Schließlich fragt man ja im Leben auch
> nicht: „Ist 10 gleich der Anzahl der Eier in der Packung?“

Ich mach es ja auch nicht. Aber so ungewöhnlich wärs für mich nicht, 
denn APL arbeitet von rechts nach links, weshalb dort 2=⍴⍴A andersrum zu 
(⍴⍴A)=2 würde (Variable A auf 2-dimensionales Array testen).

Nop schrieb:
> Der wichtigste
> Faktor ist ganz klar das US-Verteidigungsministerium. Die haben einen
> gigantischen Haushalt, und wenn die der Industrie mit Milliarden winken,
> dann kann das DoD auch sagen "wir wollen das in Ada".

Das ist seit langem nicht mehr vorgeschrieben.

/regards

> Pascal ja. Weil die Sprache ursprünglich nicht praxistauglich war und es
erst durch diverse Zufügungen diverser Compilerhersteller wurde. Dadurch
zerfiel es aber in Dialekte, und diese Fragmentierung ist Pascals
lethale Schwäche.

Die praxisbezogenen Anpassungen sind klein, und wer portiert denn schon 
ein Projekt von einer Familie zur naechsten. Ich nicht.
Embedded <-> PC. Nee.
AVR <-> PIC. Nee.

Die Anpassungen gehen uebrigens weit ueber das hinaus was C so bietet.

ich moechte einen Float als integer, resp als Array of bytes haben

Delphi :
var
 f:single; // float32
 i:integer absolute f;
 a:array[1..4] of byte absolute f;

ELab :
 f:float;
 i[@f]:integer;            // oder so
 a[@f]:array[1..4]of byte; //

Ein Ausgangsbit setzen ist :

var
 LCD_CS[@porta,3]:bit; // 3.bit von rechts

 LCD_CS:=1;

Das Bisschen Flexibilitaet bring ich dann schon noch.

Oh D. schrieb:
> Ein ADA compiler muss zertifiziert werden, um den Namen tragen zu
> duerfen, und das ist aufwendig und teuer.

Wo hast Du das denn her?

Afaik ist das genau wie bei allen anderen Compilern.

Da gibt es welche bei denen jemand geprüft hat, ob der Sprachstandard 
(oder zumindest bestimmte Teile) eingehalten wird. Für mache Anwendungen 
wird das auch gefordert.

Eine zwingende Voraussetzung ist das für den Compiler an sich aber 
nicht.

/regards

P.S: Es heisst Ada, nicht ADA. Benannt nach Ada Lovelace, die ja als 
"erste Programmiererin" gilt (irgendwo Jargang 1800+).

Als Beispiel, welche Falle einem Sprachen stellen können, die 
Bitmanipulation in PL/I, hier mit einer 8-Bit Variablen:
  dcl var bin(7); /* Das Vorzeichen geht extra */
  unspec(var) = unspec(var) & '111'b; /* Falle für C Kenner */
  unspec(var) = unspec(var) & '11100000'b; /* das passiert wirklich */
Denn Bits sind in PL/I Bitstrings und Strings sind linksbündig.

> Da gibt es welche bei denen jemand geprüft hat, ob der Sprachstandard
(oder zumindest bestimmte Teile) eingehalten wird. Für mache Anwendungen
wird das auch gefordert.

Einen (richtigen) Compiler kannst du nur verkaufen, wenn er auch 
zertifiziert wurde. Dafuer gibt es Vorschriften, da wird jedes Detail 
beschrieben, und mit Codesuiten geprueft. Der Handlungsspielraum fuer 
den Compilerbauer ist Null.
Die Vorschrift, ebenso der Sprachstandard sind kostenpflichtig, da jedes 
Jahr erneuert.

Dafuer gibt es maechtige Konstrukte, sehr maechtige Konstrukte, wo 
andere Compiler- und Librarybauer ins Schwitzen kommen.

 Select, accept a,b,c

ist aehnlich wie bei Microsoft

 WaitforMultipleObjects()
 Mit jeweils LPTR & LParam, ohne Typenpruefung

Wo der Thread auf mehrere Ereignisse gleichzeitig warten kann. Nur eben 
Typengeprueft. Das obige Konstrukt ist Teil der Sprache, nicht Teil 
einer Library.

Die moeglichen Unklarheiten einer Compilerimplementation beziehen sich 
auf die koplexere Funktionalitaet, nicht auf Bitmanipulationen und 
dergleichen.



>Nimmste in C ne Union für.

Ist aber eine Definition, nicht eine Deklaration.

Oh D. schrieb:
> Die praxisbezogenen Anpassungen sind klein, und wer portiert denn schon
> ein Projekt von einer Familie zur naechsten. Ich nicht.

Ich schon. Zentrale mit ARM, Satellit mit AVR und ein PC hängt auch 
dran. Kommuniziert wird über einen CAN Bus. Der Protokollstack vom CAN 
untergliedert sich in einen µC-spezifischen Teil für das CAN-Interface 
selbst und einen vom µC unabhängigen Teil oben drauf.

Daniel V. schrieb:
> Naja, in der Avionik und in der Raumfahrt ist diese Sprache sehr
> verbreitet.

http://stackoverflow.com/questions/9827176/what-is-the-predominant-programming-language-used-for-the-f35-lightning-ii-aircr

In der F35 nur noch mit 5% vertreten, C/C++ mit 53/35 %. Scheint so das 
dass DOD nicht mehr so sehr drauf besteht.

Helmut L. schrieb:
> Scheint so das dass DOD nicht mehr so sehr drauf besteht.

Diese Vögel sind fliegende Software und C-Programmierer sind billiger 
als Ada-Programmierer. Wenn die Kostendifferenz in der Masse grösser ist 
als die Kosten der Maschinen und der Piloten, dann geht die Rechnung 
auf.

Oh D. schrieb:
> Einen (richtigen) Compiler kannst du nur verkaufen, wenn er auch
> zertifiziert wurde.

Ada compiler: Ja.
Sonst: Nein. Z.B. ist VSxxxx afaik NICHT für irgendwas zertifiziert.

> Die Vorschrift, ebenso der Sprachstandard sind kostenpflichtig, da jedes
> Jahr erneuert.

Und warum kann man sich den letzten (!) Ada Standard Ada RM2012 dann im 
Web umsonst ansehen?

>
> Dafuer gibt es maechtige Konstrukte, sehr maechtige Konstrukte, wo
> andere Compiler- und Librarybauer ins Schwitzen kommen.
>
>  Select, accept a,b,c

Ja, das ist ja gerade eine der witzigen Sachen. Da sind Konstrukte schon 
im Sprachstandard definiert, die ansonsten eigentlich immer unportabler 
"Frickelkram" sind.

Ich glaube nicht, dass WaitforMultipleObjects() unter VxWorks 
funktioniert ;-)

/regards

Sorry ich war etwas unpraezise, bezog sich auf Ada, nicht auf was 
anderes. . Und schoen zu hoeren dass die 12 er Version herunterladbar 
ist. Ich war 10 Jahre frueher mit Ada beschaeftigt.

Naja. Bei den einfacheren Konstrukten gibt es eigentlich wenig 
Moeglichkeit zur Interpretation. Daw waitformultipleObjects ist ein oft 
gebrauchtes Konstrukt : warte auf a oder b oder timeout. Wenn man das 
selbst zusammenkleben muss gibt's Fehler.

Oh D. schrieb:
> ein oft
> gebrauchtes Konstrukt : warte auf a oder b oder timeout. Wenn man das
> selbst zusammenkleben muss gibt's Fehler.

/signed^2


Daniel V. schrieb:
> Bei
> sicherheitskritischen Anwendungen (DAL-Klassifikation: A) wird halt Ada
> eingesetzt (da kommen die 5% her).

Fordert die DAL A Ada oder ist das eine Entscheidung des Herstellers?


Stefan U. schrieb:
> Das ist ein schlechtes Beispiel, denn das ist ein Programm mit langer
> Vergangenheit. Ein erfolgreiches Programm wird nicht in einer neuen
> Sprache komplett neu geschrieben, nur um auf eine aktuellere Sprache zu
> wechseln.

Und Embarcadero lebt von Hartz 4? Denn die Preise sind eher nicht fürs 
Hobby.


/regards

Andreas H. schrieb:
> Denn die Preise sind eher nicht fürs Hobby.

Hohe Preise können aber gut auch heißen, dass es einfach zu wenige
zahlende Kunden gibt.

Turbo Pascal 1.0 wurde für USD 50 verkauft, und es verkaufte sich
massenhaft.

Fuer professionellen Einsatz sind die Compilerpreise nicht wirklich so 
interessant.

Wer hat schon nicht mal einen Tag nach einem Fehler gesucht ? Dann sind 
die 500 Euro auch weg.

Fuer Einsteiger ist der Preis sehr wichtig. Da ist es eher schwierig 
gegen Graticompiler anzukommen.

Andreas H. schrieb:
> Fordert die DAL A Ada oder ist das eine Entscheidung des Herstellers?

Bisschen unsauber formuliert. Wenn es eine sicherheitskritische 
Anwendung ist die mit DAL A klassifiziert und auch als komplex 
eingestuft wurde, beginnt der Dokumentenkrieg (ich mache es gerade im 
Hardwarebereich mit DAL-C-Geräten durch und es kann echt nerven. (kleine 
Anmerkung: Software wurde in C geschrieben ;)))

Daher muss bei der Zertifizierung abgewogen werden was sinnvoller und 
vor allem billiger ist. Natürlich entscheidet der Kunde in seiner Spec 
ob nun Ada, C, Assembler oder sonst etwas eingesetzt wird. Der Vorschlag 
welche Sprache eingesetzt wird, kommt von der jeweiligen 
Entwicklungsabteilung. Aber auch hier sind die Prozesse wieder 
unterschiedlich.

Der Vorteil von Ada gegenüber C ist, das die Validierung der Compiler 
hohe Anforderung entsprechen müssen und genau deswegen  wird gerne Ada 
im sicherheitskritischen Bereich eingesetzt. Zudem entspricht die 
Sprache der Norm  MIL-STD 1815.

Wie gesagt, das soll aber keineswegs heißen, das kein C eingesetzt wird, 
ganz im Gegenteil. Ich selber habe leider auch noch nie mit Ada zu tun 
gehabt (mal ein Skript dazu gelesen) sondern spiegelt nur mein 
allgemeines Luft- und Raumfahrtwissen wieder (wobei die Astronomie und 
Raumfahrt ein Hobby von mir ist) ;)

Gruß
Daniel

PS. Heute landet übrigens Schiaparelli auf der Marsoberfläche.
http://www.esa.int/Our_Activities/Space_Science/ExoMars/Watch_ExoMars_arrival_and_landing

Bestimmt wurde die Software auch mit Ada geschrieben ;)

Jörg W. schrieb:
> A. K. schrieb:
>> Zumal man als vorsichtiger Programmierer 4=C schreibt. ;-)
>
> Finde ich k*cke zu lesen.  Schließlich fragt man ja im Leben auch
> nicht: „Ist 10 gleich der Anzahl der Eier in der Packung?“

Naja also ich verwende umgangssprachlich durchaus auch die Phrase:
"Wenn 10 Eier in der Packung sind dann ist sie voll"

IF 10=AnzahlEierInPackung THEN PRINT "Ist noch voll" ;-)

(Habe absichtlich BASIC Syntax verwendet, weil in C das "dann" nicht so 
gut raus kommt)

Daniel V. schrieb:
> Natürlich entscheidet der Kunde in seiner Spec
> ob nun Ada, C, Assembler oder sonst etwas eingesetzt wird.

Ok. Das war auch mein Kenntnisstand.

Daniel V. schrieb:
> Zudem entspricht die
> Sprache der Norm  MIL-STD 1815.

Was jetzt nicht wirklich verwunderlich ist, den 1815A IST der Ada 
Standard (zumindest mal gewesen) ;-)


kast schrieb:
> Ich habe da (ATC-Bereich) mal im R&D Bereich gearbeitet und kann das
> nicht bestätigen.
> Das 3-fach redundante Betriebssystem und die ATC-Software war
> in C++ geschrieben. Natürlich haben wir uns an selbstdefinierte
> Standards gehalten und allerlei "Gefährliches" unterlassen.

Echt? Interessant. Darfst Du da näheres kundtun?
Ich dachte immer, das z.B. nur verifizierte RTOS/RTs benutzt werden. 
Insbesondere weil da ja fast alles "gefährlich" ist und c++ u.U. schwer 
zu validieren ist.


/regards


P.S:

Daniel V. schrieb:
> PS. Heute landet übrigens Schiaparelli auf der Marsoberfläche.
> 
http://www.esa.int/Our_Activities/Space_Science/ExoMars/Watch_ExoMars_arrival_and_landing
>
> Bestimmt wurde die Software auch mit Ada geschrieben ;)

Hoffentlich.
Ich hatte vor Jahren mal mit einem JPL Mitarbeiter Kontakt. Der erzählte 
mal (hinter vorgehaltener Hand) das bei verschiedenen Sonden auch Teile 
in Perl (!!!) gehackt wurden. Aber wohl nur "harmloser" Kram. Hat mich 
aber trotzdem nachhaltig verunsichert^^

Jörg W. schrieb:
> Sämtliche Compiler warnen sowas seit vielen Jahren, sofern
> man sie es warnen lässt und die Warnung natürlich sich zu Herzen
> nimmt.
:)
Wenn ich an meine Studentenzeit und teilweise auch an den Job direkt 
danach denke: zehntausende von Warunungen, immer alle schön ignoriert, 
Hauptsache es entsteht ein Compilat, das irgendwas macht.
Genau das hat es dann natürlich auch meistens gemacht: irgendwas.  :)

A. K. schrieb:
> Zumal man als vorsichtiger Programmierer 4=C schreibt. ;-)
Danke, Du hast mir gerade etwas beigebracht.