Hy Leute, finde irgendwie es richtig schwer sich in das AVR Studio reinzuwuchsen. Schon alleine wenn ich #include <avr/io.h> #include <avr/interrupt.h> kommen schon fehlermeldungen das er das nicht findet. ich selber weiss noch nicht mal woher er das bezieht etc. Genau so wie void für mich ein rätsel ist. Bascom finde ich sieht auf den ersten Blink viel viel Leichter aus. Oder täuscht das? gibt es eine möglichkeit einen Bascom Quellcode umzukompelieren, dass er mit dem avr studio simuliert wird? Danke schonmal Vll. mag mir mal einer per ICQ helfen wäre echt klasse 273999570
Wie wärs mit Assembler? Das ist ebenfalls sehr leicht. Wenn Du in Assembler programmieren willst, kannst Du im AVR-Studio sofort loslegen.
was ist denn assambler nun schon wieder für ne sprache :( hat vll. wer nen hinnweis?
>finde irgendwie es richtig schwer sich in das AVR Studio reinzuwuchsen. > >Schon alleine wenn ich > >#include <avr/io.h> >#include <avr/interrupt.h> > >kommen schon fehlermeldungen das er das nicht findet. Das AVR Studio ist für Assembler gedacht und die Zeilen oben sind für C. Es ist völlig egal ob C oder Bascom oder ASM, man muss klein anfangen und ein wenig lesen. Hier auf der Seite gibt es ein Tutorial in C und in Assembler.
Für den Einstieg wäre Bascom sicher besser geeignet. Allerdings verleitet einen Basic schonmal etwas zu unordentlicher Programmierung (Stichwort GOTO). Als Hauptproblem bei der freien Bascom-Version sehe ich das Codelimit auf 4k. Der Vorteil von C ist die weite Verbreitung und die Portabilität, d.h. du kannst Programme für andere/größere Controller und PC erstellen. Du solltest dir aber unbedingt etwas Literatur für Einsteiger besorgen. C hat ein paar hässliche Eigenheiten auf die man als Anfänger gerne hereinfällt (= oder ==, Pointer, Speicher vom Heap besorgen u.ä.). AVR-GCC ist kostenlos und kann auch ins AVR-Studio integriert werden. Falls du deinen AVR in Assembler programmieren willst, dann solltest du dir unbedingt mal http://www.atmel.com/dyn/resources/prod_documents/doc0856.pdf anschauen. Dort werden die Architektur und die Befehle erklärt. Eine kurze Version davon ist auch in jedem Datenblatt von Atmel mit dabei (es gibt da zwischen den Controllern durchaus kleine Unterschiede). Ist auch sehr hilfreich wenn du dir anschauen willst was der C Compiler so aus deinem Quelltext erzeugt. Die Programmierung in Assembler ist ziemlich fehleranfällig, eher langwierig und für große Programme nicht wirklich empfehlenswert.
naja so wie sich das anhört ist bascom einfach und schnell was mit anzufangen. werde ich das wohl machen danke!
Weil Basic auf nem Microcontroller lahm ist. Mit Assembler kann man seinen Code auf Geschwindigkeit und Speicherplatz hin optimieren, bei Basic nicht.
Naja, das ist alles relatov, aber aus deinem 1. Post entnehme ich das du
relativ wenig bis keine Programmiererfahrung hast.
Hier hast du ähnliche Routinen in Bascom
Sub Writecmd(byval Dat As Byte)
Local Hl As Byte
Local Startbyte As Byte
Local Nl As Byte
Local Temp As Byte
Hl = Dat
Shift Hl , Right , 4 '/ upper nibble 4 nach rechts
Nl = Dat And &H0F ' / upper nibble loeschen
If Rs <> 0 Then
Startbyte = &H1F
Spiout Startbyte , 1
End If
Spiout Nl , 1
Spiout Hl , 1
Rs = 0
Print Bin(nl);
Print Bin(hl);
Waitus 45
End Sub
in C
//Byte senden
void display_send(uint8_t byte){
LCD_DATAPORT=(byte&0b11110000); //1. High Nibble senden
display_enable();
LCD_DATAPORT=(byte<<4); //2. Low Nibble senden
display_enable();
pause_us(100);
}
und in Assembler
lcd_command: ; wie lcd_data, nur RS=0
mov temp2, temp1
swap temp1
andi temp1, 0b00001111
out PORTD, temp1
rcall lcd_enable
andi temp2, 0b00001111
out PORTD, temp2
rcall lcd_enable
rcall delay50us
ret
Im Prinzip ist nur die Syntax unterschiedlich. Klar kannst du mit Bascom
anfangen, du wirst da bestimmt auch schnell was hinbekommen nur ob du
das bis ins letzte Detail verstehst ist nicht sicher. Sobald mal etwas
abweicht und nicht so funktioniert wie es soll sucht man ne Weile.
Fängst du mit ASM an, dann kannst du im Simulator dein eigenes Programm
Anweisung für Anweisung beobachten und lernst auch schnell was der uC
bei nem Überlauf macht, warum der long Datentyp nicht so geeignet ist
für die kleinen, usw. usw.
Wenn du da einen Einblick hast und weist, was Schleifen, Verzweigungen,
bedingte Sprünge usw. kannst du easy auf jede Sprache umsteigen.
>Die Programmierung in Assembler ist ziemlich fehleranfällig, eher >langwierig und für große Programme nicht wirklich empfehlenswert. Auch in Assembler kann man ohne große Anstrengungen Programme schreiben, die wundervoll gut strukturiert und leicht zu verstehen sind. Wenn man will.
Habe Bascom gekauft und schon einige kleine Projekte mit dem AVR zusammen realisiert. Der Bascom Compiler ist sehr leistungsfähig und steht in der Geschwindigkeit dem C-Compiler kaum nach. Wenn es sein muss, dann kannst Du auch Assembler-Routinen in Bascom einfügen. Gab sogar mal einen Bericht in Elektor über Programmierung mit Bascom, wenn ich mich noch richtig daran erinnern kann. Habe auch schon AVR-MP3 Player gesehen, der mit Bascom programmiert wurde. Also, Bascom ist nicht verkehrt. Für Einsteiger würde ich auf jeden Fall Bascom empfehlen. Umsteigen kann man später immernoch, wenn es denn überhaupt noch notwendig ist.
Also Bascom ist nicht schlecht. Aber wenn du bei Null Anfängst, dann lern doch C, das kannst du dann auch für andere Sachen nutzen(Linux, Windows, PalmOS, Symbian etc)
@ Google Nutzer (Gast) >Also Bascom ist nicht schlecht. Sehe ich ähnlich. >Aber wenn du bei Null Anfängst, dann lern doch C, das kannst du dann BOAAAH!!!! C? Für Programmieranfänger? Bist du Masochist? Ich hab das grosse K****n gekriegt als ich mit C angefangn habe, und da war ich schon SEHR fit in Sachen Programmierung. Basic, Pascal Assembler. >auch für andere Sachen nutzen(Linux, Windows, PalmOS, Symbian etc) Klar, das macht man auch jeden Tag. Gerade als Anfänger. . . . BASIC ist schon für Anfänger optimal. Und die Böses Sachen ala GOTO kann man von vorn herein vermeiden. MFG Falk
Was soll denn an GOTO so bööööse sein? Gut, im heutigen Zeitalter der objektorientierten Programmierung sind effiziente Sachen generell oberböse... Aber: Ein Sprung braucht auf dem Controller weniger Taktzyklen als ein CALL/RET und keinen Stack. (Musste ich jetzt mal loswerden ;-) Gruß Jörg
Es kann nur eine Antwort geben: C. BASIC ist keine Programmiersprache oder zumindest keine, die Du dauerhaft verwenden willst. Also kannst auch gleich gescheit anfangen... OK zu Falk's Kommentar. Ich gebe zu, als ich mit 13 versucht habe, C zu lernen, bin ich auch gescheitert :D Das waren aber auch noch ein bisschen andere Zeiten. Die anfaengliche Schwelle ist hoeher aber irgendwann kommst Du so oder so zu C. Was hast Du denn fuer Vorkenntnisse?
Oh. Ich finde Bascom schon in Ordnung. Ich bin auch überzeugt davon, dass das was wir hier täglich von Bascom-Programmierern sehen und lesen, nicht wirklich etwas mit der Realität da draussen zu tun hat. Wir kriegen halt nur diejenigen zu Gesicht, die meinen mit Bascom braucht man kein generelles Verständnis der Programmierung mehr, bzw. Datenblätter - was ist das?
Das ist auch so ein Problem. Ich finde BASIC auf einer Plattform ohne Betriebssystem sowieso total daneben, das taeuscht doch nur Abstraktion vor, wo gar keine ist ;) Und genau dann passiert sowas, dass der Geist traege wird. Noch schlimmer ist es, wenn man so schon anfaengt und sich diese Marotten auch noch einverleibt...
Joerg Wolfram wrote:
> Was soll denn an GOTO so bööööse sein?
Grundsätzlich nichts. In Prinzip verbirgt sich hinter jedem Code-Block
"{ ... }" mindestens ein Goto. Von switch-case-konstrukten ganz zu
schweigen.
Zudem werden Gotos auch in vielen "professionellen" Anwendungen
verwendet z.B. dem Linux-Kernel, um mal eine nachprüfbare Quelle zu
nennen.
Jedoch bleibt zu erwähnen, daß man sich durch excessive, unbedachte
Goto-Nutzung sich seinen Code ganz schön unleserlich machen kann. Aber
Gotos grundsätzlich zu verteufeln halte ich für völlig falsch und sind
Ammenmärchen von der Uni.
In Assembler wird man um GOTOs mangels hoehersprachlichen Konstrukten nicht herumkommen. In C zeugen GOTOs allerdings von schlechtem Programmierstil. Im Einzelfall bei sehr stark optimiertem Code mag ein GOTO gerechtfertigt sein, aber wie gesagt: im Einzelfall mit Begruendung. Und das ist sehr selten der Fall. Im Mikrocontrollerbereich, also Echtzeit, mag der Hase schon wieder etwas anders liegen aber man sollte auch hier immer pruefen ob ein GOTO wirklich noetig/sinnvoll ist. Der Punkt ist einfach dass man sich mit GOTOs um guten Programmierstil herumzumogeln, Stichwort Spaghetticode. Und das ist auch die Philosophie von BASIC, als man noch mit Zeilennummern arbeiten musste, falls sich jemand erinnert - grauenvoll. Mit Abschaffung der Zeilennummern wurde auch das GOTO schlicht und ergreifend unnoetig! Die Diskussion koennte man jetzt bei strukturbrechenden Anweisungen wie continue oder break fortsetzen, aber da ist meine Meinung dass sie sinnvoll und notwendig sind, springt man ja hier nicht wirklich, sondern bricht nur aus strukturen aus, das ist Laufzeitoptimierung. Michael
Naja ich progge in VB.net, VC#, VC++, Basic und C von daher habe ich da nen überblick und auch wenn es doof klingt, aber das Buch C for Dummys ist echt zu empfehlen und sehr einfach zu verstehen. Von daher wenn noch keine Grundkenntnisse vorhanden sind, dann direkt C den der Sprung von C nach C++ ist nicht schwer. Zum Thema kannst du auch anderweitig verwenden. Grade im µC bereich wird man immer wieder mit diversen Systemen komunizieren wollen. Sprich Windows/Linux PC, Handy, PDA etc. von daher wird er es irgendwann gut gebrauchen können, wenn er sich seine eigenen APIs und Kontroll-Programme schreiben kann.
@ Joerg Wolfram (joergwolfram) >Was soll denn an GOTO so bööööse sein? Die Spaghettiprogrammierung, die zu 99% dahinter steht. >objektorientierten Programmierung sind effiziente Sachen generell >oberböse... Jaja. >Aber: Ein Sprung braucht auf dem Controller weniger Taktzyklen als ein >CALL/RET und keinen Stack. Der Spring in den Abgrund. In Assembler arbeitet man auch mit GOTO. In C ist das praktisch nicht nötig und auch nicht sinnvoll. @ Michael G. (linuxgeek) >BASIC ist keine Programmiersprache oder zumindest keine, die Du >dauerhaft verwenden willst. Also kannst auch gleich gescheit anfangen... Klar, wer Formel 1 Fahrer werden will muss nicht ein normales Auto fahren können. Also gleich mit Formel 1 anfangen. Ohje. Schon mal was von Lernkureve gehört? Den ersten Schritt vor dem zweiten machen? @ Google Nutzer (Gast) >Grade im µC bereich wird man immer wieder mit diversen Systemen >komunizieren wollen. Sprich Windows/Linux PC, Handy, PDA etc. >von daher wird er es irgendwann gut gebrauchen können, wenn er sich >seine eigenen APIs und Kontroll-Programme schreiben kann. So ein Quark. Er muss sich erstmal die Grundlagen solide erarbeiten. Dann kann er irgendwann mal nen Gang hochschalten. MFG Falk
Ich hab diesen Sommer bei uns an der Uni einen vortrag gehört der sich mit der Fehlerträchtigkeit von bestimmten Sprachen/ Systemen bzw. der Vorhersagbarkeit der Fehlerwahrscheinlichkeit beschäftigte. Laut dem Vortrag sind Programme die GOTO nutzen nicht fehleranfälliger als andere. Außerdem würden Anfänger weniger fehler machen und Gerätetreiber würden meistens von Anfängern Programmiert, aber das ist eine andere Geschichte ;) Was ich damit sagen will: GOTO kann man sehrwohl strukturiert einsetzen, man muss nur etwas aufpassen, dass man es nicht übertreibt bzw. in einer lesbaren und nachvollziehbaren Form hält. (Nein, ich programmiere kein Basic, sondern so gut wie nur Assembler und da kommt man um einen jmp eh fast nie drum rum)
Zitat "C für Dummies": "[...] Es ist bestimmt das am meisten gemiedene Wort in C. Jeder, aber auch wirklich jeder vermeidet es, ganz einfach weil es bessere lösungen gibt. Die meisten C-Bücher sagen garnichts über goto oder erwähnen es höchstens am Rande. Einmal hat es einen C-Programmierer gegeben, der eine Berechtigung für das viel verleumdete goto gefunden hat. Er hat ein C-Programm geschrieben, das ein goto verwendet, das nicht durch eine andere Konstruktion ersetzt werden kann. Es war ein Spitzenprogrammierer und hat sehr, sehr hart daran gearbeitet. Für uns ist das ohne Bedeutung. [...]" Ich habe damals in der Schule mit GWBasic angefangen. Hat mich irgendwie nicht umgehauen ;^) . Als ich mich mit Visual Basic befasste (VB für Dummies) war ich recht begeistert - weil man sich schnell und leicht eine grafische Oberfläche bauen konnte. Eigentlich ist der Stil ziemlich nahe an C, natürlich mit vielen Vereinfachungen/Abstraktionen, die aber nicht schlecht sein müssen. Allerdings rede ich hier von PC Programmierung. µC: Ich kenne BASCOM nicht wirklich, aber was ich gesehen habe hat mich bisher regelrecht abgestoßen. Ich rate zu C.
Überleg dir mal einige Anforderungen an die Sprache: 1. willst du nur diese µC Familie nutzen oder auch andere µC oder PC,....? BASCOM gibt es nur für eine µC Familie ==> willst du etwas anderes Programmieren MUSST du die nächste Programmiersprache lernen. Assembler ist ebenfalls sehr prozessorspezifich allerdings ist der unterschied zwischen den Controllern nur im Detail, zb gibt es auf (fast) allen controllern den ADD befehl, oder eineen MOV Befehel ,aber auch spezielle auf den Controller bezogene Befehle. Da die Befehle aber eine recht hohe Ähnlichkeit haben ist ein Umstieg durchaus möglich. C Hier ist der Controllertyp vollkommen egal, Der Compiler sorgt dafür das dein Code so umgesetzt wird, das für den Controller der passende Code(Assembler) entsteht. Solange nicht auf controllerhw dirket zugegriffen wird, zb IO Pin 1, reicht es den Code mit dem entsprechenden Compiler neu zu übersetzen und der Code läuft. 2. Was ist dir wichtiger, ein schnelles Ergebnis oder das Verständnis was du machst ? schnelles Ergebnis ==> Bascom, es gibt doch eine recht große Fangemeinde nach den Postings hier zu schließen. Und da dies nur einen Controllertyp betrifft, dürfte recht einfach nutzbare Hilfe zu bekommen sein. Verständnis ==> Assembler, nur hiermit lernst du wirklich warum ein Controller das macht was er macht, und was du machen musst , damit der Controller macht was du willst. Nur ein schnelles Ergebnis wirst du nicht haben, es sei denn du bist mit einer blinkenden LED zufrieden Mittelweg ==> C Mit C ist man noch relativ hardwarenah, um zu sehen was passiert, aber schon so abstrakt, das sich zügig eine Softwarstruktur erstellen lässt. Hilfe im Forum oder in anderen Quellen sind oft auf die reine C-Syntax beschränkt, da nicht jeder genau den Compiler und genau den Controller verwendet. Also muss der eigene Grips eingeschaltet werden um die Hilfe zu übertragen.
>Er hat >ein C-Programm geschrieben, das ein goto verwendet, das nicht durch >eine andere Konstruktion ersetzt werden kann. Es war ein >Spitzenprogrammierer und hat sehr, sehr hart daran gearbeitet. wechlach You made my day... :-)
Hi Als notorischer Assemblerprogrammierer noch ein Hinweis: Höhere Programmiersprache erzeugen, naturbedingt auch einen grösseren Code. Es kann also passieren, daß du bei dem gleichen Problem auf einen Controller mit grösseren Speicher ausweichen musst. Im Anhang mal ein C-Programm und der disassemblierte, vom Compiler erzeugte Assemblercode. Die eigentlich relevanten Zeilen sind gekennzeichnet. MfG Spess
>>Er hat >>ein C-Programm geschrieben, das ein goto verwendet, das nicht durch >>eine andere Konstruktion ersetzt werden kann. Es war ein >>Spitzenprogrammierer und hat sehr, sehr hart daran gearbeitet. Der Buch Autor? ;) ;) ;)
Kleiner Tipp: Wenn du noch (praktisch) keine Programmiererfahrung hast, dann fang nicht mit Mikrocontrollerbasierter Programmierung an. Weder Bascom oder C noch Assembler. Nimm irgendwas für den PC. Da gibt es tolle IDEs und die Debuggingmöglichkeiten sind weit besser als auf einem Mikrocontroller, das halte ich für den Anfang für sehr wichtig. Ich habe vor ein paar Jahren mit Visual Basic 6 angefangen und kann es auf jeden Fall weiterempfehlen. Es gibt da allerdings das kleine Problem, dass VB6 eigentlich nicht mehr "existiert" (Wird von MS nicht mehr unterstützt), daher wäre der Nachfolger VB2005 wohl besser. Schlussendlich ist es aber relativ egal mit welcher Sprache du anfängst, die Grundelemente sind bei den meisten Sprachen gleich oder zumindest ähnlich (Variablen, Prozeduren, Kontrollstrukturen, ...). Aber ganz wichtig: Besorg dir ein anständiges Buch zum Anfangen. Kostet zwar was, ist aber meiner Meinung nach wesentlich praktischer als ein Tutorial oder sonstwas im Internet, insbesondere zum Anfangen. BTW: Irgendwann wird ein Mikrocontrollerprogrammier an den Punkt kommen, an dem er den uC mit dem PC verbinden will. Dann braucht man öfters mal ein eigenes Proggi am PC und das möchtest du wohl eher nicht in (reinem) C oder Assembler machen.
spess53 wrote: > Im Anhang mal ein > C-Programm und der disassemblierte, vom Compiler erzeugte Assemblercode. Wenn man einen brauchbaren Vergleich anstellen will muss man auch realistische Programme vergleichen, keine Zweizeiler. Der Compiler erzeugt aus deinen zwei Zeilen C den minimal möglichen Assemblercode, der Rest ist die Speicherinitialisierung die für jedes Programm nur einmal benötigt wird. Theoretisch ist perfekt von Hand geschriebener Assemblercode natürlich immer kleiner oder höchstens so groß wie das was ein Compiler erzeugt, in der Praxis muss man ab einer gewissen Programmkomplexität allerdings überproportional viel Aufwand investieren um nennenswert besser als der Compiler zu werden. Besonders bei größeren Prozessoren wie dem ARM wird das sehr schwierig.
Is ja wieder klar, immer höher, schneller, weiter. Aber was will denn "Mister" überhaupt machen? Mit nem großen PC und am besten noch .net anfangen zu programmieren bringt 0,nix. Üblicherweise schreibt man ja ein Programm was etwas machen soll. Eine Zeile .net ist so abstrakt, da lernst du nix und bis du das wirklich alles beherrschst vergehen Jahre. Je kleiner die Maschine desto schneller kennt man die Stärken und Schwächen. Gerade die Sache mit dem bösen "Goto" beweist es ja. Der uC kann nunmal kein C und da ist es auch egal ob es bis zum Hirnkrebs treibt und versucht unter allen Umständen das "Goto" zu vermeiden. Der Compiler setzt es in ASM um und spätestens da gibt es wieder "Goto". Und auch mit ASM bekommt man schnell gute Sachen hin. Ein Webserver wird natürlich etwas komplizierter aber ein Anfänger Projekt ist das ja nun auch nicht. Ich habe mich am Anfang auch an Bascom versucht. LED, UART, Display, alles ging recht schnell. Schwierig wurde es als ich mal versucht ein Projekt zu realisieren wo es keine vorgefertigten Routinen gab. Da musste ich mich um alles selber kümmern und das war ein Krampf. Aber genau kann so eh keiner helfen, Probier es einfach aus oder schreib genauer was du vorhast.
Philipp Burch wrote: > BTW: Irgendwann wird ein Mikrocontrollerprogrammier an den Punkt kommen, > an dem er den uC mit dem PC verbinden will. Dann braucht man öfters mal > ein eigenes Proggi am PC und das möchtest du wohl eher nicht in (reinem) > C oder Assembler machen. Da spricht der Windowser, was? ;) Ich schreibe Kommandozeilentools grundsaetzlich in C. Falls ich eine GUI braeuchte wuerde ich wohl auf Java oder C++ ausweichen. Und eine ineffektivere (und grauenvollere) Programmiersprache als VB gibt es nun wirklich nicht. Dagegen is Prolog ja richtig entspannend! Und dass man per Hand effektiveren ASM-Code schreiben kann als ein hochentwickelter Compiler ist eine alte Legende, die sich unter Anfaengern anscheinend immernoch haelt ;) Das galt vielleicht mal vor 20 Jahren, als die Architekturen einfach und die Compiler Beta waren... Falk: Du tust ja grad so als ob C so schwer waere... sicherlich ist es schwieriger zu erlernen als BASIC, aber haeltst Du es wirklich fuer sinnvoll, auf einer Architektur wie dem AVR mit BASIC zu arbeiten? Die Sprache an sich schafft ja wohl keine Abstraktion und mit C wird man eher gezwungen sein sich mit den notwendigen Grundlagen zu befassen als mit BASIC. Ausserdem ist die Huerde, umzusteigen (Gang hoeher zu schalten in Deiner Analogie) sehr hoch wenn man erstmal mit einer Umgebung/Sprache erfolge erzielt. Warum dann also nicht gleich richtig anfangen? Michael
Condi wrote: > Is ja wieder klar, immer höher, schneller, weiter. Aber was will denn > "Mister" überhaupt machen? > Mit nem großen PC und am besten noch .net anfangen zu programmieren > bringt 0,nix. Üblicherweise schreibt man ja ein Programm was etwas > machen soll. Eine Zeile .net ist so abstrakt, da lernst du nix und bis > du das wirklich alles beherrschst vergehen Jahre. > Je kleiner die Maschine desto schneller kennt man die Stärken und > Schwächen. Äh, nur wenn man auf einer "großen" Maschine programmiert, heißt das nicht, dass man .net programmiert. Es ging den vorhergehenden Postern darum, dass man die C-Syntax erstmal am PC lernt (Ja, auch normales C gibt es am PC. Nicht nur .net), weil schlicht und ergreifend die Debug Möglichkeiten besser sind. > Gerade die Sache mit dem bösen "Goto" beweist es ja. Der uC kann nunmal > kein C und da ist es auch egal ob es bis zum Hirnkrebs treibt und > versucht unter allen Umständen das "Goto" zu vermeiden. Der Compiler > setzt es in ASM um und spätestens da gibt es wieder "Goto". Du hast es nicht verstanden oder? Man soll (angeblich) Goto in C vermeiden, weil es zu Spaghetti Code führen kann, den man dann programmiert. Da blickt dann schlussendlich niemand mehr durch. Was der Compiler hinten raus macht, ist wurscht. > Und auch mit ASM bekommt man schnell gute Sachen hin. Ein Webserver wird > natürlich etwas komplizierter aber ein Anfänger Projekt ist das ja nun > auch nicht. Ja, aber Erfahrungsgemäß (Und da werden mir auch ein paar Leute zustimmen. Okay, außer Hannes Lux, der alte Assemblerfreak! ;)) geht das Entwickeln und Schreiben, sowie Warten und später Nachvollziehen um einiges schneller in C, als wenn man sich erst in komplizierte Assemblerstrukturen reinlesen muss. > Ich habe mich am Anfang auch an Bascom versucht. LED, UART, Display, > alles ging recht schnell. Schwierig wurde es als ich mal versucht ein > Projekt zu realisieren wo es keine vorgefertigten Routinen gab. Jup, da ist man mit BASCOM eigentlich immer erledigt. > Da > musste ich mich um alles selber kümmern und das war ein Krampf. Aber höchstens in BASCOM. Wenn du einen neuen "Treiber" in C schreibst, legst du dir ein paar Files an und fängst an den zu entwickeln. PS: Ich finde sowas um einiges spannender, als fertige Blöcke zu nehmen, aber das ist meine Meinung und nicht jeder programmiert auf die Art und Weise gerne, wie ich es tue.
Simon K. wrote: > Du hast es nicht verstanden oder? Man soll (angeblich) Goto in C > vermeiden, weil es zu Spaghetti Code führen kann, den man dann > programmiert. Da blickt dann schlussendlich niemand mehr durch. > Was der Compiler hinten raus macht, ist wurscht. > >> Und auch mit ASM bekommt man schnell gute Sachen hin. Ein Webserver wird >> natürlich etwas komplizierter aber ein Anfänger Projekt ist das ja nun >> auch nicht. Eben, das ist das Thema Lesbarkeit und Wartbarkeit, beides wichtig, beides bei Assembler gegen Null tendierend. Hochsprachen wurden entwickelt, um Code menschenlesbar und wartbar zu machen, aus dem selben Grund, warum es in Hochsprachen Konstrukte wie Schleifen anstelle von Jumps gibt. Es geht um sinnvolle Abstraktion. Und C laesst dabei fast alle Moeglichkeiten offen, da es mit dem Ziel entwickelt wurde, Assembler zu ersetzen und in systemnahen Umfeldern einsetzbar zu sein. Und noch kurz zum Thema C und PC-Software: Die Systemschnittstellen ziemlich aller gaengigen Systeme (ob das nun UNIX oder Windows oder Mac oder sonstwas ist) sind nativ C. Alles andere sind Kapselungen in anderen Sprachen. C wird nur dann widerlich, wenn man sich auf die obere Haelfte der Anwendungsebene begibt -- da ist C++ mit seiner Uberkomplexitaet auch nicht viel besser. Aber davon reden wir hier ja nicht. Michael
Michael G. wrote: > Philipp Burch wrote: > >> BTW: Irgendwann wird ein Mikrocontrollerprogrammier an den Punkt kommen, >> an dem er den uC mit dem PC verbinden will. Dann braucht man öfters mal >> ein eigenes Proggi am PC und das möchtest du wohl eher nicht in (reinem) >> C oder Assembler machen. > > Da spricht der Windowser, was? ;) Ich schreibe Kommandozeilentools Exakt. > grundsaetzlich in C. Falls ich eine GUI braeuchte wuerde ich wohl auf > Java oder C++ ausweichen. Und eine ineffektivere (und grauenvollere) Ich sagte nicht, dass es nicht geht. Doch es ist nunmal einfacher, sich schnell eine Oberfläche zusammenzuklicken als auf irgendwelche externe Tool zurückzugreifen. Kommandozeilenproggies sind da wohl eine Ausnahme, die sind in C(++) in der Tat recht leicht zu realisieren (In den meisten anderen Sprachen auch). > Programmiersprache als VB gibt es nun wirklich nicht. Dagegen is Prolog > ja richtig entspannend! Wichtigster Grundsatz wenn du C programmierst: Hasse BASIC und Microsoft erst recht, wie? Ausserdem: Irgendwas musst du mit der Rechenleistung der heutigen PCs ja anfangen, da wird ein Programm doch wohl noch etwas ineffizient sein dürfen ;)
Ihr widersprecht euch doch selber! Vb 2005, C# ist nunmal .net. >nicht, dass man .net programmiert. Es ging den vorhergehenden Postern >darum, dass man die C-Syntax erstmal am PC lernt (Ja, auch normales C >gibt es am PC. Nicht nur .net), weil schlicht und ergreifend die Debug >Möglichkeiten besser sind. C ist C, ob für nen großen oder nen kleinen Rechner. Im AVR Studio sehe ich genau was er macht und wo es hängt. Im C Builder unter Windows viel mir das schon oft schwer. Schon allein weil der so viel Funktionen nutzt die man so garnicht sieht. Speicher für ne Variable so als Beispiel, im AVR kannst du dir die Addresse anschauen und selbst bei 64Kb RAM ist das noch verständlich. Bei 4GB RAM und 2 Kernen und dann noch Realmode und was es alles gibt. Viel Spass. >Entwickeln und Schreiben, sowie Warten und später Nachvollziehen um >einiges schneller in C, als wenn man sich erst in komplizierte >Assemblerstrukturen reinlesen muss. Ohne gute Doku ist das immer schwer bis unmöglich. In Myrtle gab es C++ Funktionen mit so vielen Parametern und Pointern, da hat man selbst mit Doku Stunden gebraucht die zu verstehen. ASM ist nicht kompliziert, man kann damit nur Bits schubsen. Schon an diesem #include <stdio.h> int main(void) { printf("Hallo Welt!\n"); return 0; } kleinen Codefragment, kann man nicht erkennen was passiert. Gibt er es auf dem Bildschirm, Drucker, Netzwerk oder gar über UART aus. Mal angenommen er gibt das auf dem Bildschirm aus. Was passiert im Hintergrund? Interessiert keinen, funktioniert ja. Irgendwann wird das dann alles so Abstrakt, da kann dann jeder Programmieren. Da sieht ein Programm nur noch so aus: Programm(); Erklärt aber immer noch nicht was der OP erreichen will.
Hi Michael wrote: >'Eben, das ist das Thema Lesbarkeit und Wartbarkeit, beides wichtig, >beides bei Assembler gegen Null tendierend.' Wenn dem so wäre, würdest du bis heute kein C, Basic oder andere Compiler haben und dich noch mit irgendwelchen rudimentären 'Betriebssystemen' herumschlagen. Oder womit sind CPM und die ersten Compiler geschrieben worden? Und da hat sich bis heute auch nur bedingt etwas geändert. Wenn ich mir z.B. die Source der Math-Unit von Delphi ansehe, dann besteht die fast zur Hälfte aus Assemblercode. Die Lesbarkeit und Wartbarkeit von Code hat nur sehr bedingt mit der verwendeten Sprache sondern mehr mit dem Programmierstil zu tun. MfG Spess
Michael G. schrieb:
> In C zeugen GOTOs allerdings von schlechtem Programmierstil.
Du bist doch der Linuxgeek:
$ cd linux-2.6.23.9
$ find -name \*.c -exec grep '\<goto\>' {} \;|wc -l
47024
$ find -name \*.c|wc -l
9474
d.h. ca. 47000 Gotos verteilt auf 9474 .c-Dateien. Das sind 5 Gotos pro
.c-Datei!
Wenn goto schlecht ist, dann ist es auch Linux ;-)
Die vielen Gotos haben aber durchaus ihren Sinn. Sie verbessern nicht
nur die Effizienz, sondern vor allem auch die Lesbarkeit der
Programme, so paradox es klingt. Spaghetti produzieren nur diejenigen,
die nicht wissen, wie man Gotos richtig einsetzt.
Historischer Rückblick: CP/M wurde in weiten Teilen in PL/M geschrieben. Nix Assembler.
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.