C oder Pascal?

Hallo,
ich selber habe mir letztes Jahr die gleiche Frage gestellt mit dem 
eindeutigem Ergebniss C.
Das Winavr ist wirklich ein sehr starker Compiler für umsonst, und bei 
jedem anderem Prozessor wirst du auch wahrscheinlich erstmal einen 
C-compiler bekomen (oft auch für Umsonst) bevor du einen, mit Mühe 
bezahlbaren, Paskal-Compiler kommt. Unter Windoof werde ich auch 
weiterhin bei Delphi bleiben, aber die Hardwarenähe von C ist bei uC's 
echt ein erheblicher Vorteil und der Aufwand bei der Portierung ist 
sicher bei C am geringsten.
Gruß Bernhard

Hallo nochmal,

ich habe mir gerade mal das Demo von CodeVision herunter geladen, 
installiert (der AVR-GCC ist mir ehrlich gesagt zu unkonfortabel) und 
mir einige Beispiele angeschaut. Tut mir leid, aber ich kann einfach 
keine großen Unterschiede zu Assembler feststellen. Vermutlich liegt's 
auch daran, dass das Ganze für mich noch ungewohnt ausschaut, aber ich 
find's trotzdem fast noch kryptischer als Assembler und ich kann auf 
Anhieb keinen Vorteil sehen. Genau das war seinerzeit übrigens für mich 
ein Grund, in Sachen PC-Programmierung auf Delphi zu setzen (und ich 
hab's nicht bereut). Zur Zeit lade ich mir gerade den Pascal-Compiler 
vom E-Lab herunter. Das was ich bisher davon im Internet gesehen habe, 
klingt vielversprechend und ist womöglich wegen meiner Delphi-Erfahrung 
sinnvoller. Tja, noch bin ich selbstständiger Entwickler, aber falls 
sich das mal ändern sollte braucht wahrscheinlich niemand einen Mann, 
der sich mit C nicht auskennt; ach, ich bin hin- und hergerissen .....

Gruß Weide

hallo weide,
auf jeden fall c.

wie andreas schon geschildert hat, machst du die hardwarenahen 
funktionen für jeden controller extra.
dann brauchst du dich bei der eigentlichen projektarbeit garnicht mehr 
so um den controller zu kümmern.
das einbinden und compilieren der richtigen funktionen übernimmt dann 
die allseits beliebte makedatei für dich.


wenn du bei dem nachfolgenden programmabschnitt keinen unterschied zu 
einem assemblercode feststellen kannst, dann weiss ich auch nicht 
weiter.
der code sollte auf allen c++ und wahrscheinlich auch c compilern 
ausführbar sein.

int main(void)
{
  unsigned char i;
  unsigned channel = 0;
  uart_init(channel, 9600, EVEN, D8, S1);

  for (i = 0 ; i < 5 ; i++)
  {
    send_uart_buffer(channel, "Ziffer = ");
    send_uart_char(channel,i+0x30);
  }
  return 0;
}

noch eine kleine frage, was kann an einem compiler eigentlich 
unkonfortabel sein?

die eigentliche frage sollte eher sein:
nehme ich einen c oder einen c++ compiler. und da ist der gcc  fast 
unschlagbar.

oryx

Hallo Oryx,

vielen Dank für Deine Ausführungen und Dein Beispiel. Die selbe Routine 
in Assembler wäre übrigens ähnlich kurz ;-).



===================================================
noch eine kleine frage, was kann an einem compiler eigentlich 
unkonfortabel sein?
===================================================

Damit meinte ich wohl eher die Entwicklungsumgebung - sorry. Wenn ich 
z.B. wie bei Codevision oder AVRco Anfangs die Portpins und Pull-up's 
per Mausklick initialisieren kann und auch per Mausklick die Funktionen 
für eventuelle Interrupts definieren kann, dann nenne ich das 
komfortabel bzw. es spart einfach Zeit. Es macht für mich keinen Sinn, 
wenn ich mit einer Hochsprache arbeite und dabei keine Zeit spare.

Ich habe mir übrigens die Demoversion von AVRco, also die 
Pascal-Entwicklungsumgebung, mal genauer angeschaut und ich bin echt 
begeistert. Ich würde es sofort nehmen wenn C nicht so weit verbreitet 
wäre. Irgendwie erinnert mich das Ganze an VHS und Video-2000. Letzteres 
war das bessere System, aber durchgesetzt hat sich VHS ....

Gruß Weide

willst du Lämpchen an und aus schalten und ein paar Statusinformationen 
zum PC schicken - da geb ich dir recht, das kann man in Assembler 
genauso schnell erledigen wie in C oder irgendeiner anderen Hochsprache. 
Kritischer wirds, wenn du wirklich Berechnungen anstellen mußt, damit 
meine ich etwas umfangreichere Sachen als die Addition zweier 
integer-Variablen. Ebenso ist eine Hochsprache ein Riesenvorteil, wenn 
du mehrdimensionale Arrays bearbeiten willst, da geht dir in Assembler 
ganz schnell die Übersicht verloren. Selbst bei eigentlich primitiven 
Vergleichen von z.B. signed-Variablen (=,>=,<=,<) bist du in Assembler 
jedesmal am Grübeln - wie war das doch noch mal??
Auch Schleifenkonstruktionen sind erheblich einfacher zu machen, und, 
für mich das wichtigste, das Programm ist einfacher les-und wartbar, 
viel übersichtlicher. Du brauchst dir keine Gedanken zu machen, wo, wie 
und welcher Form eine Variable abgespeichert wird, und es wird nicht 
vorkommen, daß du aus Versehen einen SPeicherplatz 2 oder mehr Variablen 
zuordnest. Bei Assemblerprogrammen passieren einfach mehr 
Schusslichkeitsfehler, der Test/Fehlersuche nimmt einen großen Teil der 
gesamten Programmentwicklungszeit ein, insgesamt dauert es wesentlich 
länger, ein Programm in Assembler zu erstellen.

Hallo Weide,
auch ich hab mir die Demo's von ELAB und Codevision gezogen bevor ich 
auf gcc gegangen bin. Ergebniss: es ist nett ein Entwicklungswerkzeug zu 
haben, bei dem man sich die Sachen so einfach zusammenklicken kann 
(Bascom AVR Basic finde ich auch ganz nett..) . Anfangs war ich von ELAB 
totel begeistert - hab mir auch ne uneingeschränkte Version für den 
Mega8 gekauft - und habe angefangen zu programieren. Was nützt mir die 
Möglichkeit auf ein LCD zuzugreifen, wie unter Windoof und das sogar 
noch auf dem guten Simulator zu testen, wenn ich nicht bestimmen kann 
welche Pins an welchem Port liegen (beim Mega8 ein echtes Problem wegen 
den Doppelbelegungen). Unter GCC kann ich mir aus einer Unmenge LCD 
Beispielen, das aussuchen was ich brauche und umschreiben Bsp.: 4bit 
Daten auf Port x und LCD Steuerleitungen auf Port y ... Geht bei den 
'komfortablen' Compilern nicht (das ist nur ein Beispiel von vielen). 
Das Zauberwort heist GNU, allso offengelegter Code.  Ein Pascal, das mir 
nicht wirklich Einblick auf die verwendeten units gewährt, kann ich 
nicht gebrauchen.
Gruß Bernhard

Hallo crazy horse,

da hast Du Recht. Ich habe mir zwar in den Jahren so einiges an 
mathematischen Routinen in Assembler zusammengebaut, aber sie 
einzusetzen kostet trotzdem jedes Mal wieder Zeit ("welche Register 
werden doch gleich noch benutzt?"). Bei Arrays muß ich Dir auch Recht 
geben - klar.

Allerdings finde ich ein C-Programm auf Anhieb auch nicht sonderlich 
lesbar, was allerdings wohl hauptsächlich daran liegt, dass ich C noch 
nicht beherrsche. Ein Pascal-Programm finde ich da wesentlich lesbarer 
(was daran liegt, dass ich's beherrsche ;-)). Ich als Pascalmensch suche 
z.B. bei if-Anweisungen in C immer das "then". Dieses eine Wort dürfte 
den Compiler wohl kaum in seiner Geschwindigkeit beeinträchtigen, würde 
aber die Lesbarkeit enorm steigern. (auf das "else" konnten die Macher 
von C dann wohl doch nicht verzichten ;-)).


Hallo Bernhard,

ich habe mir das Ganze nun noch nicht soo genau angeschaut, aber die 
Units sind doch immer *.pas bzw *.c (?) Dateien und entsprechend 
editierbar.

hallo weide,
deine Antwort an crazy horse mit den mathematischen routinen ist doch 
das todschlagsargument gegen reine assemblerprogramierung. wenn ich 
jetzt noch provokativ nach dem zeitaufwand und den sinn deines 
quellcodes bei einem wechsel der controllerfamilie frage, bin ich ja auf 
eine antwort gespannt.

hast du eigentlich schon mal einige deiner delphi funktionen für den avr 
durchcompilieren lassen.

bei mir läuft teilweise die gleiche quellcode mit dem gnu-compiler und 
dem borland-c++-builder.
bei kompliziereren sachen ist das debugging auf dem pc ja doch etwas 
schöner. wenn die sachen dann laufen, einfach für den controller neu 
compilieren und fertig.

mir ist die portabilität doch sehr viel wichtiger als das letzte bißchen 
geschwindigkeitsgewinn.

vielleicht sollten wir mal telefonieren.

oryx

Hallo Oryx,

============================================================
deine Antwort an crazy horse mit den mathematischen routinen ist doch 
das todschlagsargument gegen reine assemblerprogramierung. wenn ich 
jetzt noch provokativ nach dem zeitaufwand und den sinn deines 
quellcodes bei einem wechsel der controllerfamilie frage, bin ich ja auf 
eine antwort gespannt
============================================================

Ich sollte vielleicht lieber noch einmal meine Eingangsfrage in 
Erinnerung rufen: "C oder Pascal?". Natürlich sind meine mathematische 
Routinen ein großes Problem in Sachen Portierbarkeit und auch in 
allgemeiner Handhabung. Wenn's nicht so wäre, würde ich nicht über eine 
Hochsprache nachdenken.

Den mittleren Teil Deines Postings habe ich leider nicht ganz 
verstanden. Wie? Man kann seinen AVR-Quellcode mit borland c++ erstellen 
und auch (zunächst)compilieren?

Aber wie gesagt, es geht gar nicht um die Frage "Assembler oder 
Hochsprache", sondern eher um die Wahl der Hochsprache. Momentan 
tendiere ich (auch aufgrund Eurer Antworten) eher zu C, zumal ich zudem 
mit Signalprozessoren arbeite, für die es ausschließlich nur 
(unbezahlbare) C-Compiler gibt.

Gruß Weide

Machs dir einfach und nimm C.
Wenn du es mal drauf hast ist es einfach nur geil.
Und für die Zukunft bist du auch gerüstet.
Max