mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Bascom oder C verwenden?


Autor: Mister (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: AVRFan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie wärs mit Assembler?  Das ist ebenfalls sehr leicht.  Wenn Du in 
Assembler programmieren willst, kannst Du im AVR-Studio sofort loslegen.

Autor: Mister (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
was ist denn assambler nun schon wieder für ne sprache :( hat vll. wer 
nen hinnweis?

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
www.gidf.de

Autor: AVRFan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Condi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/...

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.

Autor: Mister (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
naja so wie sich das anhört ist bascom einfach und schnell was mit 
anzufangen.


werde ich das wohl machen danke!

Autor: Condi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eher nicht, wirst du aber schnell merken.

Autor: Mister (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wieso eher nicht begründe doch mal

danke

Autor: Jemand (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Weil Basic auf nem Microcontroller lahm ist. Mit Assembler kann man 
seinen Code auf Geschwindigkeit und Speicherplatz hin optimieren, bei 
Basic nicht.

Autor: Condi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: AVRFan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Roland (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Google Nutzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Joerg Wolfram (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Niels Hüsken (monarch35)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Google Nutzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Hauke Radtki (lafkaschar) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: T. H. (pumpkin) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ralph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ü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.

Autor: AVRFan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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... :-)

Autor: spess53 (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>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? ;) ;) ;)

Autor: Philipp Burch (philipp_burch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Condi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Philipp Burch (philipp_burch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Boink...

Autor: Condi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ekschperde (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Historischer Rückblick:
CP/M wurde in weiten Teilen in PL/M geschrieben.
Nix Assembler.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.