Hallo, nach Jahren der Assemblerprogrammierung (hauptsächlich AVR) möchte ich nun doch mal eine Hochsprache probieren. Beim Programmieren von PC-Programmen benutze ich Delphi, deshalb interessiert mich natürlich der Pascal-Compiler (von E-Lab). Allerdings frage ich mich, ob ich damit nicht einen Vorteil von C, nämlich die Portierbarkeit auf andere Systeme verspiele. Pascal-Compiler sind ja lange nicht so verbreitet. Wenn ich mir hingegen Hochsprachenprogramme genauer anschaue, scheint es mit einer einfachen Portierbarkeit eh' nicht allzu weit her zu sein, gerade bei Benutzung prozessorspezifischer Komponenten wie z.B. UART. Habt ihr vielleicht ein paar Tipps und Hinweise für mich, die mir meine Entscheidung erleichtert? viele Grüße Weide
Ich würde sagen an C führ kein Weg vorbei. Für praktisch jeden Controller gibt es C-Compiler, oft sogar wie beim AVR kostenlos, Pascal dagegen ist eine echte Ausnahme. Die Portierbarkeit ist eigentlich bei C kein großes Problem; wenn man alle Hardwarezugriffe in Makros oder Funktionen kapselt, dann kann man schon mal relativ problemlos Teile eines AVR-Programms z.B. auf MSP430 übernehmen (vor allem weil es für beide den gleichen Compiler gibt (GCC (kostenlos (aber gut (ja, ich bin LISP-geschädigt))))). Mit dem UART z.B. gibt es sicherlich keine Probleme: einfach die Funktionen uart_send(), uart_receive() und uart_init() anpassen, und schon läuft die Sache. Dass das bei kompletten Projekten die Gebrauch von Interrupts, Timern usw. machen etwas anders aussieht, ist natürlich klar. Gruß Andreas
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
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.