mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik BASCOM vs. C


Autor: pet (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich versuche gerade meine Ersten schritte in C (GCC) mit AVR.
Zuvor habe ich immer BASCOM benutzt und bin damit auch sehr zu
frieden.
Bloß wird man immer schief angeguckt wenn man erzählt, dass man mit
BASIC programmiert und nicht in C.

Habe jetzt in GCC mit Printf einen einfachen String (Hello world) über
den UART ausgegeben.
Allerdings war ich von der Codegröße (ca. 3KByte) schon geschockt; mit
0s Optimierung.
BASCOM benötigt dagegen nur ca. 160 Bytes (print „HALLO WELT“)

Sobald man in GCC irgendeine fertige Funktion aus der Bibliothek
verwendet wird der kompilierte Code meist sehr groß - viel größer als
ein vergleichbares Programm in BASCOM.

Was ist nun der bessere Compiler?
Ich verstehe die Welt nicht mehr.

: Gesperrt durch Moderator
Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bleib bei Bascom!!!
Was gehen dich die anderen an.

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Genau! Mach einfach wie du am besten klarkommst. Ich bleib auch beim
BASIC und das auf allen für mich interessanten Plattformen. Was da
nicht geht binde ich in Assembler direkt mit ein. Da es ohnehin eine
Gewissens-/Glaubensfrage ist welche Sprache nun die Beste ist stören
mich gelegentliche abfällige Bemerkungen wegen meiner BASIC-Präferenz
nicht im geringsten. Letztendlich zählt das Ergebnis wenn man nicht
durch äussere Einflüsse gezwungen ist was Bestimmtes zu verwenden.

bye

Frank

Autor: Toni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann mich meinen Vorrednern nur anschließen. Nutze weiterhin Bascom.
Daran ist nichts verwerfliches, auch wenn es die C'ler anders sehen.
Aber irgenwie wüssen sie ja Ihren höheren Aufwand bei der
Programmierung der Atmel-Chips rechtfertigen. Aber warum einfach
programmieren wenn es auch umständlich geht. Hauptsache C.

Toni

Autor: Marc Meise (bytewood) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Pet,
ich habe mit BASCOM angefangen. Grund dafür war, dass ich BASIC in den
verschiedenen dialekten recht gut verstehe, und kann, aber von
Controllern keine Ahnung hatte.  Mit C hatte ich nur wenig erfahrung.
Was also lag näher, einen Controller kennen zu lernen und ihn dann auch
gleich in einer "bekannten" Sprache zu programmieren. Von daher grßes
Lob an den Entwickler von BASCOM.
Ich meine aber C lernen ist ein Muss (was für ein C auch immer)!
Das schöne an C ist, dass es standardisiert ist - was bei BASIC nicht
der Fall ist, danz zu schweigen von den Visual Geschichten (VB und
REALBasic).

Wenn man sich erst mal in C eingearbeitet hat, dann programmiert man
damit fast genauso schnell wie in BASCOM. Die Strukturen in den
Programmiersprachen sind ja alle gleich (Schleifen, Verzweigungen,
etc.), nur die Syntax ist halt eben etwas anders - reine
Gewöhungssache.

Eine Andere Sache ist, dass "alle Welt" mit C programmiert und es C
auf jeder Plattform gibt - was das Portieren recht einfach macht. Bei
BASIC sieht es schon ganz anders aus.

Für mich gilt: Ich bin kein großer programmierer, und meins Codes sind
"quick and dirty" (BASIC und C).
Wenn etwas schnell gehen soll, dann BASCOM - wenn es ordentlich werden
soll, dann C. Mit ordentlich meine ich: wissen, was das programm wann,
und zu welcher Zeit genau macht (Hardwarenah).

Ich finde es gibt schon einen unterschied zwischen z.B.:

BASCOM:

config portb = output
portb=1
oder bei Rechnungen:
D= A+B
D= D+C

und in C:

DDRB=0xff;
portb=0xff;

D=A+B+C

Eine andere heikle Sache sind Arrays:
BASCOM nur eindimensional
C n-dimensional

Ich betrachte beide gleichwertig, mit ihren jeweiligen vor- und
Nachteilen (Ist bei mir eher ne Sache von Lust und Laune und natürlich
der Aufgabe).

Was Dein Problem mit der Größe angeht:
Ich vermute mal, dass Du in C den prinf-Befehl ausgesucht hast.
Sobald der im Programm auftaucht, bläht der das Hex-File auf, aber wenn
Du ihn dann öfter einsetzt, macht es keinen Unterschied in der größe
mehr aus. C braucht eine Menge an Rechenoperationen, um diesen
Ausgabebefehl umzusetzen, da man mit ihm wunderbar formatieren und
rechnen kann (siehe Syntax prinf).

Hoffe, ich konnte Dir weiterhelfen
Gruß
Marc

Autor: pet (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für eure Antworten.

>Ich meine aber C lernen ist ein Muss (was für ein C auch immer)!
Genau das ist der Grund warum ich auf C umsteigen will.

An der FH hatten wir „nur“ µC in Assembler programmiert und C und C++
für Windows Anwendungen.
Privat mache ich halt sehr viel mit BASCOM, weil es einfach schneller
geht.
Wenn ich das meinen Mitstudenten erzähle werde ich schon fast
ausgelacht:)

Das C Sprachkonzept gefällt mir allerdings viel Besser, weil es
Hardware näher ist. Außerdem werden C-Kenntnisse in fast jeder
Bewerbung vorausgesetzt.

Was mich in GCC stört ist, wenn man andere Include Dateien einbindet
die Hexdatei sehr groß wird (größer als das in BASCOM der Fall ist).
Besonders bei Mathematischen Berechnungen.

Ich könnte zwar mit sehr viel Zeitaufwand die Benötigten Funktionen mit
den Standart C-Sprachelementen selber schreiben, dann kann ich es aber
auch gleich mit dem gleichen Aufwand in Assembler machen.

Dann ist der Vorteil einer Hochsprache aber verloren gegangen.
Assembler ist halt doch das Beste, allerdings für mathematische
Berechnungen (sin usw.) ist mir es zu aufwendig.

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

Bewertung
0 lesenswert
nicht lesenswert
Zur Groesse:
Nun ja, irgendwo muessen diese Funktionen ja auch implementiert
werden. Und bei bestimmten Funktionen (zb. printf) zieht das
dann eben einen ganzen Haufen anderer benoetigter Funktionen
wie einen Rattenschwanz nach sich. Das gute daran: Du zahlst
diesen Preis nur ein einziges mal. Wenn Du einen 2-ten printf
mit drinn hast, dann kostet das nicht nochmal den ganzen
Rattenschwanz.

Konkret muss printf ja auch rechnen koennen (fuer formatierte
Zahlenausgaben). Also kommt schon mal die halbe Bibliothek fuer
Berechnungen mit dazu. Je nach Hersteller kann das auch heissen,
dass die komplette Floating-Point Bibliothek mit dazukommt (denn
du koenntest ja auch Gleitkommezahlen ausgeben). Hier hat C ein
grundsaetzliches Problem. Eine der Philosophien von C war, das
jeglicher I/O nicht Bestandteil der Sprache an sich sind (so
wie if, for, while) sonder ueber Funktionen erledigt wird. Daher
gibt es auch nur ein 'Rundumschlag'-printf, dass eben alle
Moeglichkeiten abdecken muss. Alle Moeglichkeiten heist aber
auch, dass dies printf-Funktion auch Ausfuehrungspfade (zb. Ausgabe
von Gleitkommezahlen) enthaelt, die von Deinem Program ev. niemals
benutzt werden. Das kann aber der Linker wiederum nicht feststellen
und ist daher gezwungen die halbe Floating Point Library dazuzugeben.
Und so kommt eins zum anderen und am Ende hast Du 3 KByte Runtime-
Library, die nur durch einen simplen printf dazukommen.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Einbinden von Headerdateien verändert die Größe des erzeugten Codes
überhaupt nicht, das geschieht erst durch das Verwenden von Funktionen
aus zum Programm dazuzulinkenden Libraries.

Und bei der Auswahl von denen muss man halt sehr gewissenhaft umgehen;
wer für die einfache Ausgabe von Texten (ohne Formatierungsfunktionen
zu verwenden) ein printf aufruft, muss die ziemlich große
Printf-Library verwenden. Wer dann noch ungeschickterweise die
Floating-Point-Version verwendet, zahlt doppelt drauf, auch wenn das
Programm nur ein

  printf("hello world\n");

enthält.

Verwendet man beispielsweise puts statt printf und verzichtet auf die
Floating-Point-Unterstützung, dann sieht die resultierende Codegröße
auch schon gaaanz anders aus.

Ansonsten ist BASCOM aufgrund seiner Einschränkungen an manchen Stellen
ein ziemlicher Krampf;
einen Ausdruck wie

  a = (b + c * (d / e)) & 0x123F;

muss man in BASCOM in ziemlich viele Einzelausdrücke zerlegen ...

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

Bewertung
0 lesenswert
nicht lesenswert
Wobei mir absolut nicht klar ist, wie man so einen Krampf
nur machen kann. Das Parsen von arithmetischen Ausdruecken
samt Punkt-vor-Strich-Regelung ist vom Schwierigkeitsgrad her
'Compilerbau - 3. Unterichtseinheit'

Autor: mount /dev/hda9876 katzeklo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meine Meinung dazu: C ist eine Programmiersprache, BASIC ist Müll.

Autor: thkais (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Kar Heinz:
Ganz einfach: Man spart den Stack, den man braucht, um den Ausdruck zu
parsen. Aber, ganz ehrlich gesagt, mir gefällt das besser, als manches
C-Konstrukt, in dem möglichst unleserlich die gesamte Berechnungsformel
in eine Zeile gedrückt wird.
Ich stand auch vor der Entscheidung BASCOM oder C. Vorher alles in
Assembler programmiert, aber irgendwann wirds dann doch
unübersichtlich, wenn die Projekte größer werden. Vor C habe ich mich
lange gedrückt, weil mir die Syntax überhaupt nicht so richtig gefallen
wollte.
Meine Entscheidung gegen Bascom fiel aus zwei Gründen: Bei Interrupts
werden alle Register auf dem Stack gesichert und das ganze Basic
(nicht nur bei Bascom) ist mir zu sehr Black-Box.
Unterm Strich muss jeder selbst wissen, mit welcher Sprache er zurecht
kommt, und da würde ich mir auch nicht reinreden lassen. Die Typen, die
über Bascom lachen, sind sich offensichtlich der Unzulänglichkeiten von
C nicht bewusst. Sehr amüsant und durchaus nicht unwahr:
http://www.math.uni-bremen.de/~thielema/CHater.html
Diese Argumente auswendig lernen und denjenigen vor die Füsse werfen,
die meinen, C wäre das Maß der Dinge.

Autor: Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich finde Bascom bzw. Basic allgemein einen guten Einstieg in die
Programmierung.
Für manchen reicht es auch, die vielen fertigen Funktionen zu
benutzen.
Leider verliert man dadurch den Hardware-Bezug bzw. man baut ihn gar
nicht erst auf.
In C muß man sich eigentlich jede Funktion selber bauen, wobei man
natürlich auf vorhandene Algorithmen / Bibliotheken zurückgreifen
kann.
Bibliotheken haben wie schon erwähnt das Problem, dass sie meist einen
Rattenschwanz mit sich herumtragen, den man u.U. gar nicht braucht.
Dafür kann man sich in C aber die "abgespeckte" Version der Funktion
selber bauen. In Bascom stelle ich mir das bei weitem schwieriger vor.
C ist IMHO mehr etwas für Leute, die sich wirklich mit dem Controller
beschäftigen und ihn optimal nutzen wollen.
Bascom bleibt da etwas hardwareentfernter.

Autor: thkais (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag: Basic Müll? Verzieh Dich in Dein Katzenklo. Du hast Null
Ahnung.

Autor: pet (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir ist schon klar, dass der printf Befehl sehr mächtig ist und deshalb
auch viel Programmspeicher benötigt.
Für einen einfachen String über UART auszugeben benutze ich ja
eigentlich auch nicht die printf Funktion.
Da kann man mit ein paar Zeilen seine eigne Ausgabefunktion schreiben.
Es ging halt nur um das Prinzip.

>das Einbinden von Headerdateien verändert die Größe des erzeugten
>Codes
>überhaupt nicht, das geschieht erst durch das Verwenden von
>Funktionen
>aus zum Programm dazuzulinkenden Libraries.

Das ist schon klar!
Das habe ich auch so gemeint wie du geschrieben hast.

@mount /dev/hda9876 katzeklo
Darüber kann man sich streiten.
Die meisten C-Anhänger behaupten das BASIC nichts taugt.
Wenn man in C nur vorgefertigte Funktionen verwendet und nicht genau
weiß was sie machen ist C auch nicht viel besser als BASIC.
Da lobe ich mir Assembler

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eines fällt doch auf: Leute, die in Basic programmieren, diffamieren
keine anderen. Es sind immer wieder C-Programmierer, die solche
Streitereien anfangen. Das beste Beispiel ist der Urheber dieses
Threads. In Basic hat alles wunderbar geklappt, aber eine Rotte
von C-Programmieren musste natürlich alles kritisieren.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zu dem Printf-Problem:

Der Vergleich ist absolut, ja ABSOLUT inakzeptabel (zwischen print
(BASIC) und printf (C)) !

Wo man bei BASIC nur Text ausgeben kann, geht bei printf eigentlich
nahezu alles!

Hier ist eine Dokumentation von printf und den Formatierungsparametern,
und das, was man dort zum formatieren zur Verfügung hat, ist IRRE.
http://www.cplusplus.com/ref/cstdio/printf.html

Und das, bietet BASIC's print niemals.
Was eher dem 'print' in BASIC gerecht wird (vom Funktionsumfang) ist
sowas hier:
void uart_puts(*s)
{
  while(*s)
  {
    while(UDRE..);
    UDR = *s;
    s++;
  }
}  
(Mal so grob hingekritzelt)
Und ich würde fast sagen, dass dies kleiner ist als 160 Byte.

Zum Programmiersprachensystem:
Man muss beachten, dass BASIC sehr stark abstrahiert. Das hat den
Vorteil, dass sowas natürlich leicht zu erlernen ist. Ich denke hier an
Qbasic oder so, wo man in 5minuten ein 4-Gewinnt programmieren konnte.
Auf der anderen Seite gibts hier aber auch starke Nachteile, die oft
missachtet werden, da man mit ihnen noch nicht konfrontiert wurde (In
form von unbekannten Prozessorabstürzen o.ä.). Hierzu zählt erstmal,
dass man eigentlich nur wenig Wissen braucht, um den Chip erfolgreich
in BASIC zu programmieren. Das ist schlecht! Leute schauen nicht ins
Datenblatt, wissen nicht über die Funktionen bescheid und so weiter.
Zweierlei weiß der Programmierer nicht, was der Prozessor zu der
Ausführungszeit genau macht. BASIC ist sozusagen ergebnisorientiert.
(Byte kommt an vom UART, oder halt nicht). Macht man sowas in C, weiß
man eigentlich, was der Compiler da genau hingestrickt hat. Fertiges
Assemblerfile wird sogar öffenbar gemacht, sodass man sich die
Rechenarithmetik des Compilers mal anschauen kann, oder ähnlich.
Ich finde da hat man schon einen sehr großen Vorteil durch. Weiterhin
kann man mit C viel optimierteren und angepassteren Code machen, als
mit BASIC. Und da bin ich eigentlich fest von überzeugt. Allein die
n-dimensionalen Arrays sind doch schon genial. Man kann Messwerte in
ein Array schreiben, dass in Monaten und wiederrum Tagen unterteilt
ist. Sowas geht in BASIC nicht. Man kann Structs Definieren, um dem
ganzen Programm Ordnung zu geben. Man kann Unions deklarieren, die
einen ungeheuren Teil zur programmierer-eigenen Programmoptimierung
beitragen können!

Ich sehe BASIC(zumindest BASCOM) eher als "Baukasten". Sowas, wie ein
Elektrokasten. Das hierrein stecken, das so, und schwups schon gehts.
C ist eine richtige Programmiersprache, die wirklich die Ressourcen
eines Prozessors und seinen Komponenten ausschöpfen kann und viel
anpassbarer entgegenkommt als BASCOM.

PS: Lassen wir Assembler mal außenvor, denn beide Compiler müssen vom
BASIC, bzw C Code erst Assemblercode generieren bevor sie in eine
Programmierfertige Datei packen können.
PPS: Ich rede hier über BASIC und C für Microcontroller (Speziell
BASCOM und den AVR-GCC). Basic für den PC ist natürlich kein Baukasten
(oder zumindest ein nicht so großer)

(Alles nur meine Meinung)

Autor: zugucker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
seit ihr witzig!
diese diskussion ist völlig überflüssig und dient NIEMANDEN.
das kommt mir vor wie ein schw...-längen vergleich...
Lächerlich über so etwas seitenlange abhandlungen zu schreiben!

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

Bewertung
0 lesenswert
nicht lesenswert
thkais:
> Ganz einfach: Man spart den Stack, den man braucht, um den
> Ausdruck zu parsen.

Hae? Das passiert doch zur Compilezeit, wen interessiert da der Stack?

> Aber, ganz ehrlich gesagt, mir gefällt das besser,
> als manches C-Konstrukt, in dem möglichst unleserlich die
> gesamte Berechnungsformel in eine Zeile gedrückt wird.

Und schon wird aus einem Bug ein Feature...

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

Bewertung
0 lesenswert
nicht lesenswert
@thkais

> Ganz einfach: Man spart den Stack, den man braucht, um den
> Ausdruck zu parsen.

Du meinst vielleicht 'um den Ausdruck auszurechnen' wenn man
eine Stack Maschine implementiert.
Richtig. Allerdings. Die meisten arithmetischen Ausdruecke
brauchen eine Stack-Tiefe von deutlich weniger als 10. Und wenn
man tatsaechlich mal drueber ist, kann der Compiler das immer
noch mit Leichtigkeit feststellen und eine entsprechende Meldung
ausgeben.

> Aber, ganz ehrlich gesagt, mir gefällt das besser,
> als manches C-Konstrukt, in dem möglichst unleserlich die
> gesamte Berechnungsformel in eine Zeile gedrückt wird.

Was bitte ist an
   Distance = sqrt( (x1 - x2) * (x1 - x2 ) +
                    (y1 - y2) * (y1 - y2 ) );

oder Gott bewahre

   Distance = sqrt( sqr( x1 - x2 ) + sqr( y1 - y2 ) );

oder von mir aus (wenn man dem Optimizer nicht traut)

   dx = x1 - x2;
   dy = y1 - y2;
   Distance = sqrt( dx * dx + dy * dy );

unuebersichtlich ?

Die Alternative:

   dx = x1 - x2;
   dy = y1 - y2;
   Dist = dx * dx;
   Temp = dy * dy;
   Dist = Dist + Temp;
   Dist = sqrt( Dist );

also dass nenn ich unuebersichtlich. Das muss man erst mal sehen,
das sowas einen Phytagoras implementiert.

Fuer mich ist sowas ganz einfach Faulheit der Compilerprogrammierer.
Mein Tiny-Basic Interpreter der auf einem Z80 in 8KByte EPROM lief
konnte das schon vor 25 Jahren.

Autor: Marc Meise (bytewood) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Martin
>Eines fällt doch auf: Leute, die in Basic programmieren, diffamieren
>keine anderen. Es sind immer wieder C-Programmierer...

Du sprichst mir aus der Seele.

Warum nicht einfach den passenden Compiler (+IDE) zur entsprechenden
Anwendung/Vorhaben/Projekt aussuchen. Schnell und ergebnisorientiert
(Baukastenprinzip) oder nach Lust und Laune "Bits-Shiften" und den
Controller RICHTIG kennenlernen.
(An alle Flamer: "Bits Shiften" ist NICHT böse, oder wertend
gemeint)
Gruß

Autor: Hubert.G (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin der Meinung: Ein schlechte Programm (Programmiersprache usw.)
das man gut beherrscht ist besser als das Beste das man nicht
beherrscht.
Ich programmiere übrigends in C.
Grüße Hubert

Autor: Hubert.G (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine kleine Korrektur und Ergänzung.
Ich bin der Meinung: Ein schlechtes (einfaches) Programm
(Programmiersprache usw.)das man gut beherrscht ist besser als das
Beste das man nicht beherrscht.
Es sollte einen aber nicht davon abhalten etwas besseres zu lernen.
Ich programmiere übrigends in C.
Grüße Hubert

Autor: Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin der Meinung, dass es nicht an BASCOM oder C liegt, sondern an
den Leuten, die meinen, dass sie sich, weil sie ja mit Basic arbeiten,
um nichts (Datenblatt, µC-Aufbau) kümmern müssen, sondern einfach ins
Blaue "programmieren".
Diese Leute stossen dann auf Probleme und wissen wegen fehlender
Grundlagen nicht, woran es liegt.
Dabei handelt sich aber eher um einen kleinen Teil der
BASCOM-"Programmierer", die da die Quick'n'verydirty-Methode
ausprobieren und auf den Bauch fallen. Dieser kleine Teil an
"Programmierern" (Programmieren hat was mit strukturierter/logischer
Vorgehensweise zutun, was "Programmierer" leider nicht verstanden
haben) fällt durch sein "Fragengestelle" blöd auf, und erfahrene
Programmierer (meist C- oder ASM-Porgrammierfähig) schütteln dann den
Kopf und werfen alle µC-BASIC-Programmierer in einen Topf.
Simon hat es schon beschrieben: PRINT und printf kann man nicht
wirklich (objektiv) vergleichen. So gehen viele Leute aber auch an die
Programmierung heran (gefährliches Halbwissen...).

Ich bewundere jeden, der mit Mikrocontrollern und Prgrammieren anfängt,
egal wie er/sie es macht und in welcher Sprache er/sie programmiert.
Ich habe auch keine Probleme, Leuten zu helfen, die Ihr Problem
(verständlich) schildern und auch zeigen, dass sie sich mit dem Problem
auseinandergesetzt haben (Stand da nicht was in der Forem-Hilfe, wie der
Ablauf einer Lösungsfindung aussehen sollte?).

@thkais:
der Link ist was schönes... Werd ich mir ausdrucken und aufhängen...

Autor: Marc Meise (bytewood) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Pet
>Außerdem werden C-Kenntnisse in fast jeder
>Bewerbung vorausgesetzt.

Ist es nicht schön, wenn Du in einer Bewerbung noch BASCOM-AVR neben C
(und Assembler) hinzufügen kannst?

Gruß

Autor: Sebastian Heyn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ mount /dev/hda9876 katzeklo:

du hälst dich wohl für ganz schlau. aber nicht mal den eigenen namen
schriebst du hin, weil du selber weisst was für ne grütze du
schreibst!

Diese diskussion bin ich echt satt! überall gibt es die.  Basic ist
echt scheisse wenn es um zeitkritische sachen geht, weil man oft nicht
sehen kann was der controller macht.  Ich bin selber BASCOM user
(vollversion) und sehr zufrieden, was den umgang mit strings etc
angeht. wenn man viel mit displays etc arbeitet und daten bearbeitet
und umwandelt ist echt ganz super. Sachen wie Textausgabe auf TV und so
weiter kann man allerdings echt vergessen.

Viele verwechseln BASCOM mit nem BASIC interpreter. Der code ist was
viele sachen angeht mindestens genauso effizient, wenn nicht sogar noch
besser als C code. Und arroganz von vielen C-Programmieren sollte man
gekonnt ignorieren. Mir geht es um eine einfache lösung und mit bascom
bin ich bis jetzt noch nie falsch gefahren.

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

Bewertung
0 lesenswert
nicht lesenswert
Zustimmung, aber das hier ist schlicht und einfach falsch:
> Der code ist was viele sachen angeht mindestens genauso effizient,
> wenn nicht sogar noch besser als C code.

Autor: castle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Bloß wird man immer schief angeguckt wenn man erzählt, dass man mit
BASIC programmiert und nicht in C."

du musst es als progger selber wissen ob du schnell ein ergebnis haben
möchtest und der weg und die einzelnen routinen egal sind , dann nimm
basic, oder aber du möchtest dich mit dem interessanten einzelnen
avr-befehlen aus der defdatei vom avr befassen, dann nimmst du
win-avrc.

ich glaube der zweite weg ist interessanter.

castle

Autor: Marc Meise (bytewood) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Sebastian
Ich gebe Dir in beiden Punkten recht.

Ob nun der erzeugte Code in BASCOM etwas etwas kleiner, oder etwas
größer ist, ist IMHO nun wirklich egal. Man sucht sich ja schliesslich
seinen AVR für eine Anwendung aus, die man realisieren möchte und sorgt
dafür, dass der Flash nicht zu klein ist, da kommt es auf ein paar byte
nun wirklich nicht an.
Ich denke auch, dass die wenigsten Anwendungen extrem Zeitkritisch
sind( was wiederum die Diskussion über die verschiedensten C Compiler
anheizen könnte).
Von daher lande ich wieder bei "Geschmacksache"
Ich programmiere in BASCOM und in C
Gruß

Autor: pet (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich wollte jetzt kein Glaubenskrieg ob jetzt BASCOM oder C besser
auslösen!
Ich finde es sehr Interessant alle Meinungen von BASCOM und C Usern zu
hören (lesen).

Es ging mir eigentlich darum, dass ich mehrere kleinere Testprogramme
in BASCOM und GCC geschrieben habe (die das selber machen) und jedes
mal war der BASCOM Code kleiner.
Das soll jetzt nicht heißen, dass der kleinere Code auch besser ist.
Vielleicht zahlt sich auch die gut durchdachte Struktur von C in
größeren Projekten aus.
Ich habe immer gedacht, bzw. gesagt bekommen, dass ein C Compiler des
effizienteren Codes liefert.
Es kommt halt darauf an wie der Compiler die Befehle in
Maschinensprache umsetzt.
Und nicht um die Syntax der entsprechenden Hochsprache.

> Der code ist was viele sachen angeht mindestens genauso effizient,
> wenn nicht sogar noch besser als C code.

Wenn Effizienz = Maschinencodegröße ist, kann ich die obige Aussage bis
jetzt nur bestätigen.

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@pet:

Wie groß wird denn der Code, wenn du das gleiche Programm in ASM
schreibst?

...

Autor: pet (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@
Marc Meise
Schlechten bzw. großen Code mit Rechenpower zu kompensieren finde ich
aber auch nicht den richtigen Weg.

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

Bewertung
0 lesenswert
nicht lesenswert
Wenn diese Testprogramme printf() zur Ausgabe von konstanten Strings
verwenden, dann ist der Vergleich wertlos. Falls du einen vernuenftigen
Verlgleich willst, schau dir die Ergebnisse fuer verschiedene Aufgaben
im Disassembler an. Dann siehst du z.B. auch das oben angesprochene
Problem dass Bascom bei Interrupthandlern alle Register auf dem Stack
sichert, unabhaengig davon ob das ueberhaupt noetig ist.

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Schlechten bzw. großen Code mit Rechenpower zu kompensieren finde
> ich
> aber auch nicht den richtigen Weg.

Wird aber beim PC seit Jahren so gemacht...

...

Autor: pet (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@
HanneS... Lux (HanneS)

Habe ich jetzt noch nicht gemacht.
Aber bestimmt bis um Faktor 10 kleiner.
Assembler ist mir aber in den meisten Fällen, gerade bei mathematischen
Berechnungen, zu aufwendig.

>Wird aber beim PC seit Jahren so gemach
lol



@
Andreas Schwarz

Ich gebe zu der Vergleich mit printf ist etwas unglücklich
Ich habe auch oben irgendwo geschrieben, dass ich t printf in einem
„richtigen“ C Programm nicht dazu nutzen würde um nur ASCII Zeichen
auszugeben, da hat man in ein paar Zeilen seine eigen Ausgabefunktion
viel schnelle geschrieben.

Autor: Marc Meise (bytewood) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Pet
es bleibt nur die Frage, ob diese "Effizienz" in der Zeitfrage
unbedingt notwendig ist.
Für einfache Steuerungen ist das IMHO egal.
Bsp.: Schrittmotorsteuerung: ob nun die Spulen ein paar Mikrosekunden
früher oder später ihren Saft erhalten ist egal.
Beim Auslesen eines ADC mit hoher Frequenz kann es schon anders
aussehen.
Wenn Du demnächst etwas größere Programme schreibst, dann wirst Du
bestimmt feststellen, dass sich BASCOM und C in der Hex-Filegröße nicht
viel tun. In der Geschwindigkeit auch nicht. Bleib Flexibel!

Das mit der "Glaubensfrage" ist so ne Sache, die man vornehmlich in
deutschen Foren (haufenweise) findet. In amerikanischen, englischen und
französischen Foren kommt diese Art der "Glaubenskriege" wesentlich
seltener vor. Die sind auch viel netter zueinander und vorallem
konstruktiver.
Aber, ein deutscher "Glaubenskrieg" ist doch extrem witzig zu lesen,
da kann man doch prima "ablachen" (und 100 Jahre alt werden :-).
Gruß
Marc

Autor: castle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Ich denke auch, dass die wenigsten Anwendungen extrem Zeitkritisch
sind( was wiederum die Diskussion über die verschiedensten C Compiler
anheizen könnte)."

es gibt für uns eigentlich nur den winavr-c.
freie software, wird gepflegt und eine riesengrosse programmsammlung
und erfahrungsschatz in den deutschen foren.

die anderen beiden kosten 130 - 900 euro.

castle

Autor: castle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
und in den deutschen foren keine oder wenig hilfe von den beiden
letztgenannten.


castle

Autor: castle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Es ging mir eigentlich darum, dass ich mehrere kleinere Testprogramme
in BASCOM und GCC geschrieben habe (die das selber machen) und jedes
mal war der BASCOM Code kleiner."


junge, dann hast du in "gcc" nicht die richtigen optimierungschalter
gesetzt.
aber lese dir das "gcc"  noch einmal durch, wo die optimierungen
gesetzt werden.
es ist aber noch kein meister vom himmel gefallen.

Castle

Autor: castle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"In der Geschwindigkeit auch nicht."


stimmt nicht....

in winavr-c kann ich ein fbas-vidiosignal mit 20 buchstaben und 12
zeilen darstellen ohne asm-code mit dem avr8-16mhz. buchstaben sind
7pixelbreit und 8 pixel hoch.

in bascomm schaffe ich noch nicht mal ein timing mit der for-schleife
um nur eine ruhiges signal zu bekommen ohne textdarstellung.

castle

Autor: Sebastian Heyn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist deshalb weil in bascom erst alle register gesichert werden, wenn
ein interrupt passiert...

Wie gesagt für einfache anwendungen wie Fernbedienung auslesen etc
reicht bascom allemal

Autor: Axel R. (axelr) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
darf man FastAVR erwähnen?

Die Demo hat zwar nur 100Zeilen. Aber man kann super im generierten
*.ASM File "klauen" :-o .

Achso - komplexe Ausdrücke gehen in einer Zeile. Ausser bei Peek und
Poke. Da NICHT!!

Hat noch paar andere Bugs, als Ideenlieferant jedoch ganz nett.

Gruß
AxelR

Autor: Horst-Otto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
n00b ist zu blöde, den Compiler richtig zu benutzen -> C ist scheiße,
ganz klar!

Wer in BASIC programmiert schneidet sich nur ins eigene Fleisch. Soll
mir nur recht sein. Wer von BASIC nicht von alleine nach >1 Woche
umsteigt, der hat vielleicht auch nicht die kognitiven Voraussetzungen
dafür. Solche Leute sollte man nicht versuchen zu überzeugen. Es gibt
schon genug schlechten C Code.

Übrigens war BASIC nie als ernsthafte Programmiersprache gedacht. Das
"B" steht für "Beginners'". Irgendein Idiot ist dann trotzdem auf
die Idee gekommen, BASIC für reale Anwendungen zu vermarkten.

Übrigens programmiere ich auch ab und zu in BASIC. Mein Taschenrechner
kann nix anderes.

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Aber man kann super im generierten
> *.ASM File "klauen" :-o .

Hi Axel...
Ich glaube nicht, dass das die Verfechter von BASCOM interessiert.
Ich denke eher, dass sie eine Hochsprache benutzen, um sich nicht um
ASM oder die spezielle Hardware kümmern zu müssen. Und dann ist der
Baukasten namens BASCOM eine gute Wahl, denn es gibt sofort schnelle
Erfolge. Man muss sich allerdings auf die mitgelieferten Bibliotheken
beschränken. Will man etwas, wofür keine Bibliothel mitgeliefert wurde,
dann steht man schnell orientierungslos im Wald.

Wer (beim AVR, nicht beim PC!!!) eine Hochsprache benutzt, um sich vor
ASM und Hardwarekenntnisse zu drücken, der wird früher oder später auf
die Nase fallen. Der gravierende Vorteil von C, die Portierbarkeit von
Programmen, greift beim AVR sowiso nur bedingt, da die
Hardwareausstattung der unterschiedlichen AVRs sehr unterschiedlich
ist.

Wer aber ASM kann und die Hardware-Architektur verstanden hat, die
Hochsprache nutzt, um sich etwas Arbeit zu ersparen, der ist mit C
besser beraten als mit BASCOM. Und wenn es BASIC sein muss, dann wird
er FAST-AVR vorziehen, da er die Ergebnisse (in ASM) nachvollziehen
kann. BASCOM zeigt das Ergebnis (den ASM-Code) nicht oder nur mit
Kunstgriffen, das (und die von Rahul genannten Gründe) ist der Grund,
warum ich persönlich BASCOM meide, obwohl ich auf anderen Systemen gern
in BASIC programmiere.

Ich habe nichts gegen Leute, die BASCOM benutzen und damit zurecht
kommen.

Ich habe aber etwas dagegen, wenn man Null Ahnung von AVRs hat, meint,
mit BASCOM die Welt einreißen zu können, ohne das Datenblatt des AVRs
und die BASCOM-Hilfe lesen zu müssen, und dann hier im Forum
herumattert, dass man ihm gefälligst zu helfen hat.

...

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

ich weiß garnicht was die Diskussion soll. Wenn jemand seine aktuelles
Problem in BASCOM lösen kann dann ist BASCOM für ihn die perfekte
Lösung. Selbiges gilt im Umkehrschluß für C.

C ist mit Sicherheit nicht der Weisheit letzter Schluß. Es ist sogar
teilweise eine grauenvolle Programmiersprache was z.B. die Vermeidung
von Fehlern durch die Sprache angeht. Das es sich so weit verbreitet
hat liegt wohl darin begründet das nahezu jedes OS (im PC Bereich
Windows und Linux, diverse Unixe) in C geschrieben ist. Damit ist die
typische Schnittstelle zum OS ein C-Schnittstelle und die Benutzung aus
C herraus ist einfach. Das aber ein OS in C geschrieben wird liegt darin
begründet das der erste Compiler für eine Architektur üblicherweise ein
C Compiler ist. Eine Art Teufelskreis.

Matthias

Autor: Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Marc: unsere Schrittmotoren arbeiten mit einer Chopperfrequenz von
400kHz (ja nicht nur 40kHz), da kann es schon noch auf die ein oder
andere Mikrosekunde ankommen. (Bei uns übernimmt das ein FPGA...)

@Castle: welche beiden meinst du? IAR liegt bei ~2kEuro...

Ich denke, BASCOM ist für den Privat-Heim-Anwender völlig in Ordnung.
Die meisten Firmen erwarten C-Kenntnisse; ASM-Kenntnisse sind fürs
Debuggen eh unerlässlich...

Manche Firmen erwarten auch VHDL-Kenntnisse; das aber meistens eher von
E-Technikern...

Irgendwer meinte mal in irgendeinem Thread was davon, dass man bei der
Auswahl eines Programmers (STK500 und Tiny45...) auch Drittanbietern
eine Chance lassen sollte. BASCOM gibt es nur von einer Firma;
AVR-C-Compiler kenne ich inzwischen 3 (GCC, CV und IAR) ...

[OT]
Merkt man eigentlich, dass ich endlich einen festen Job habe? freu
[/OT]

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> OT

Scheen, ich freu mich für dich... Ist es denn in deiner Heimat (bei den
Sprotten)?

...

Autor: Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja, und ich kann sogar (wenn ich meinen Kopf dolle verdrehe) auf den
Kanal gucken...

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Pet

"Es ging mir eigentlich darum, dass ich mehrere kleinere
Testprogramme
in BASCOM und GCC geschrieben habe (die das selber machen) und jedes
mal war der BASCOM Code kleiner."


Häng doch einfach mal einige dieser Beispiele in Bascom und C als
Dateianhang ran und wie groß die in Bascom sind.

Dann kann man mal sehen, ob da irgendwas beim Übersetzen schief
gelaufen ist.
Bzw. Tips geben, wie man dies und jenes in C besser schreibt.


Und laß Dich nicht beirren.
Wenn man einmal mit Arrays, Unions, Structs und Pointern gearbeitet
hat, möchte man sie nicht mehr missen.

In Codevision sind auch viele vordefinierte Black Boxes dabei, was
allerdings den Code unportabel macht und einen im Unklaren läßt, welche
Ressourcen dabei drauf gehen und welche Konflikte entstehen (z.B. ein
Timer wird belegt).

Ich benutze den WINAVR.


Peter

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achja:
Nur so Nebendran:
Ich bin natürlich kein intoleranter Mensch. Nein im Gegenteil. Ich
persönlich höre Metal, und der geneigte Metal-fan kennt die
Metal'schen Regeln: Andere Musik zwar nicht gut finden, aber nicht
gegen sie vorgehen oder sie beschimpfen. Und genauso verhälts sich
eigentlich mit den Programmiersprachen.

Wie schon gesagt: BASCOM ist für mich eher ein Baukasten.
Und auf Fragen hier im Forum (auch BASCOM, habe ich schließlich auch
mal programmiert) antworte ich auch. Bzw ich will sagen, dass ich nur,
weil derjenige BASCOM benutzt, nicht helfen soll, stimmt nicht. Aber,
wie schon gesagt, nur, wenn derjenige auch Ahnung hat und nicht einfach
Fragen stellt ohne sich vorher Erkundigt zu haben.

PS: Programmiere etwas C, und etwas ASM. Bin ja nur der Hobby-progger
;) Benutze auch den WINAVR. Für ASM benutze ich Atmels AVR Studio.

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also, es stimmt schon, daß BASCOM an einigen Stellen unhandlich ist,
siehe Arrays, Eingabe von mathematischen Gleichungen. Trotzdem arbeite
ich mit BASCOM, weil ich bisher immer gut damit klar gekommen bin. Es
hat eine nette Entwicklungsumgebung einen integrierten Simulator und
eine Menge Funktionen zum Ansteuern von externer Hardware. Ich habe
auch schon überlegt, auf C umzusteigen, aber solange das nicht nötig
ist, bleibe ich bei BASCOM; hat halt bisher immer gut gereicht.

PS: Habe ich das richtig verstanden? Sind hier ein paar Kieler am
Start? :-D

Grüße

Autor: Marcus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also, hier nu meine meinung:

ich habe, denke ich mal, von allen hier die wenigste ahnung, und bin im
dilpom (atm) heftigst mit C in die µC prog. eingetiegen; dennoch wurde
ich hier bei meinen (sehr oft) dämlichen fragen, gut aufgenommen [was
ein satz!].

kurz un knapp, was auch schon gesagt wurde (ich wiederhole dies nun mit
ca. 3 atü auf'm kessel):

1. Jeder so, wie er am besten zurecht kommt.

2. ALLES (wirklich, alles hat VOR- und NACHTEILE)

3. Prost!

... naja, deswegen... ich meine man muss immer genau schauen und
abwägen... sicherlich gibt es leute die es besser können, oder
programme/compiler/etc. die schneller sind... .. .

Autor: Marcus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...ohjee... was hab ich'n da für'n mist geblubbert...

vergesst's... prost!

:-)

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

Bewertung
0 lesenswert
nicht lesenswert
@peter dannegger
So, ich habe jetzt mal ein kleines Testprogramm angehängt.
Es gibt ein Integer Zahl über den Uart aus (µC Mega32).
Um ungefähr die gleiche Größe in GCC wie in BASCOM zu erreichen musste
ich alle einzelnen Funktionen mit den C Standard Sprachelementen selber
schreiben.
Dann kann ich aber auch gleich ASM benutzen, das wäre auch nicht mehr
viel mehr Arbeit gewesen.

GCC: 440 bytes, mit Os Optimierung
BASCOM:474 bytes

In diesem Fall ist der GCC-Code etwas kleiner, weil ja auch nur das
nötigste implementiert wurde.

Autor: Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Daniel: ja... 1-2.

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

Bewertung
0 lesenswert
nicht lesenswert
Hier noch in BASCOM

Autor: Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tja, pet, schon hast du deine eigene These widerlegt.
Ich bezweifle, dass du das in ASM besser hinbekommst als in C.
Dass der BASCOM-Code kleiner erscheint, liegt einfach daran, dass
BASCOM von sich aus schon diese Funktionen implementiert hat.
Du könntest deine C-Routinen auch in ein Headerfile schreiben, dann
würdest du auf die gleiche Quelltextlänge wie in BASCOM kommen.

Autor: pet (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir ging es darum:
Sobald ich vorgefertigte Funktionen aus einer anderen INCLUDE Datei in
meinem Programm benutzte ist der Maschinen-Code von GCC fast immer
größer ist als das bei einem vergleichbaren BASCOM Programm der Fall
ist.

Sobald ich nur die Standard Sprachelemente in C nehme und versuche nur
mit denen zu Recht zu kommen, ist die Codegröße ungefähr gleich.
Wenn ich in GCC printf verwendet hätte, hätte ich gleich wieder ca. 2,9
Kbytes.
Egal wie mächtige printf gegenüber BASCOMs print sein mag.

Genau dies ist mir bei meinen ersten GCC Versuchen gegenüber BASCOM
aufgefallen.
Habe eigentlich gedacht, dass die GCC Libs effizienter sind, als die
von BASCOM.
Und wollte einfach mal eure Meinung dazu wissen.

Autor: castle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Castle: welche beiden meinst du? IAR liegt bei ~2kEuro...



codevision und keil

Autor: Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
klar ist sie ewffizienter: Sie kann wesentlich mehr bei nicht wesentlich
mehr Code...

Autor: pet (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, sie kann mehr, ist ja auch viel umfangreicher.
Ich will doch gar nicht darüber streiten was nun besser ist :)

Autor: Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
klingt aber so...

Autor: Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir fällt gerade noch ein Nachteil von BASCOM ein:
Bei BASCOM hat viele schöne vorgefertigte Prozeduren.
Wenn Atmel oder so (BASCOM gibt's ja nicht nur für AVR) einen neuen
Chip herausbringt, dauert es bis die neuen Funktionen unterstützt
werden. Wenn ich mir jetzt in C meine eigenen Bibliotheken
"zusammenbastel", dann kann ich da relativ schnell Änderungen
einpflegen...

Diesen Nachteil sehe ich halt in der abstrakten Arbeitsweise von
Basic.

Übrigens kann man deinen C-Code von oben auch noch verkürzen...
Und effizienter durch die Verwendung von Interrupts gestalten...

Autor: pet (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch was:
Ich tendiere ja auch zu C.
Sonst würde ich ja nicht von BASCOM auf C umsteigen wollen.
Mir ist bis jetzt nur aufgefallen, dass der Mehraufwand in C sich in
der Maschinencodegröße kaum oder gar nicht bezahlt macht.

So jetzt ist aber Schluss :)

Autor: peter dannegger (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@Pet,

das Print-Beispiel ist wirklich etwas unglücklich gewählt.

Es klang ja so als hättest Du noch andere Beispiele.


Die ganze Print-Sache wurde von den AVR-GCC-Entwicklern extrem
aufgeblasen und geht über fopen(), malloc() und sonst son Tod und
Teufel. Die Idee dahinter war, daß Ausgaben beliebig umgeleitet werden
können sollen, bloß wer braucht das schon.

Daher schreibe ich mir die UART-Init/-Ausgabe auch selber.


Die Zahlenwandlung kann man aber der Funktion itoa() überlassen (siehe
Anhang), muß man also nicht zu Fuß machen.


Der WINAVR ist natürlich auch nicht so kompakt, wie kommerzielle
Compiler.


Peter

Autor: Jens500 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich bin beim Einstieg in die Mikrocontroller-Welt vor ca. 3 Jahren über
die C-Control mit Basic Interpreter, kurzem Ausflug in AVRCO  sowie ASM
und längerer Verweildauer in der Bascom Welt nun (endlich bzw.
zwangsläufig) bei C angekommen.

Gerade im Hobby-Bereich geht es doch um Erfolgserlebnisse. Am Anfang
hat man dopch schon genug mit der Hardware zu kämpfen; wenn dann die
verwendete Software auch noch so "anspruchsvoll" wie C ist, dann
kommt schnell die Frustation.

Hätte ich dies faszinierende Hobby mit C beginnen müssen, hätte ich es
wohl schnell wieder ad acta gelegt.

Langer Rede kurzer Sinn, ich bin nun bei C (WINAVR) gelandet und werde
dies auch mit grossem Interesee auch weiter verfolgen.

Jens

PS. Die freie Verfügbarkeit des gcc-compilers ist natürlich ein Grund
für seinen Erfolg.

Autor: MNR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die beiden Code-Beispiele zeigen doch genau das, was hier mehrfach schon
angeklungen ist:
- BASCOM: Einfach und schnell zum Ergebnis kommen, ohne die Hardware
kennen geschweige denn programmieren zu müssen
-C: Kenntnis der Hardware nötig, dafür alle Möglichkeiten und damit
auch Schwierigkeiten sind vom Programmierer zu nutzen/lösen

Die Größe des Codes scheint mir dabei vergleich- und damit
vernachlässigbar, was nicht wirklich verwundern kann.

Fazit: Jedem das, womit er am besten zurecht kommt, wie viele schon
geschrieben haben...

Gruß,
Matthias

Autor: Nils B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also, mir ging es ähnlich:

Hab während meinest Studiums auch C++ und C51 gelernt, hätte meine
ersten Projekte auch gerne in C programmiert, doch mangels guter
Software bin ich dann auch zu Bascom gekommen, und bin sehr zufrieden
damit. Im Endeffekt "sieht" ja keiner, mit welcher Software man es
programmiert hat, hauptsache das Ding läuft, und so ist es bei mir
auch, es läuft alles so wie ich es mir ausgedacht habe, und das ist für
mich erstmal die Hauptsache...

Klar, einige dinge gehen mit Bascom nicht, aber da muss man dann halt
kreativ sein... ;-)

Autor: Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Klar, einige dinge gehen mit Bascom nicht, aber da muss man dann halt
kreativ sein... ;-)

Das muß man bei C (und allgemeinem Programmieren) sowieso sein...

Autor: Toni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Matthias
"- BASCOM: ......ohne die Hardware
kennen geschweige denn programmieren zu müssen"

Hier kommt sie wieder zum Vorschein, die Überheblichkeit der Leute
welche denken nur wer in C kraxelt kann programmieren.

Hast Du dir eigentlch schon mal die Hilfe zu Bascom oder die
Programmbeispiele reingezogen? Wohl eher nicht, ist ja unter Deiner
Würde.
Bei diesen Dokumenten wird sehr wohl deutlich, das es ohne Kentnisse
der Hardware auch in Bascom nicht geht.

Übrigens lassen sich mit Bascom auch zeitkritische Sachen entwickeln
wenn man nicht nur den WAIT-Befehl kennt.

Toni

Autor: Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Toni: Dann gehörst du vermutlich zu denjenigen, die nicht bei jedem
Problem sofort im Forum posten "HILFE! Geht nicht! Warum?".

Der Unterschied bezüglich der Hardwarenähe liegt daran, dass BASCOM
einem das Auseinandersetzen mit den einzelnen Register-Flags
"erspart", um die man in der Regel bei C nicht herumkommt (siehe
Beispiele von Marc).
Wie schon erwähnt: BASCOM ist OK. Man kann damit gute Sachen machen;
manche vorgefertigten Funktionen sind nicht so optimal implementiert
(ob man die manuell umgehen/verbessern kann, weiß ich nicht).
Und die meisten Fragen in Bezug auf BASCOM-Probleme kommen von
BASCOM-Benutzern, die sich nicht eingehend genug mit dem Problem oder
der Programmiersprache oder was auch immer beschäftigten, sondern
lieber "rumheulen"...

Autor: MNR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Toni
Du hast es negativ interpreriert, so war es aber nicht gemeint.

Die Beurteilung, was unter meiner Würde ist und was nicht, steht dir
allerdings nicht zu.

Gruß,
Matthias

Autor: Norbert C. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@thkais

Vielen Dank für den netten Link zu der C-Hasser Seite! Im Gegensatz zu
vielen anderen in diesem Forum habe ich (Baujahr 60) noch selbst
miterlebt, wie die Programmiersprache C "in Mode gekommen ist".

Damals hatte ich schon einige Erfahrung in anderen Sprachen (Assembler,
Basic, Fortran, Pl1) und habe C gehaßt wie die Pest. Später hatte ich
mich einigermaßen damit angefreundet aber die ständige Fehlersuche
durch die fehlenden Laufzeitkontrollen und die absolut lose Typbindung
sind wirklich ein Krampf im A...

Man kann C als eine Art standardisierte, etwas komfortabel gestaltete
Assemblersprache bezeichnen aber mehr ist das wirklich nicht. Die
später daraus entstandenen Derivate wie C++, C# usw. sind meiner
Meinung nach absolut sinnlos und nur aufgrund von Modetrends
(Objektorientierung usw.) entstanden.

Vor kurzem bin ich per Zufall über die (seltsamerweise recht
unbekannte) Programmiersprache Ada gestolpert. Das war für mich eine
wirkliche Offenbarung, die mir die Augen geöffnet hat. Endlich mal
wieder eine wirklich gute Programmiersprache, die auch tatsächlich die
Bezeichnung "universell verwendbar" verdient. Gegenüber C das
absolute Kontrastprogramm. Endlich laufen die Programme auf Anhieb auch
so, wie man es gerne möchte und den Debugger braucht man fast nicht
mehr. Ominöse Fehler mit unklaren Ursachen gehören seitdem für mich zur
Vergangenheit. Ich kann nur jeden ermutigen, es mal damit zu versuchen.
Der Anfang wird zwar schwer sein aber dann ... ;-)

Unter Windows oder Unix (Linux, HPUX) programmiere ich nur noch mit Ada
und ich bin großer Hoffnung, dass die Portierung von GNAT für AVRs
(AVR-Ada) weitere Fortschritte machen wird. Denn eigentlich wurde die
Programmiersprache Ada ursprünglich zur Programmierung eingebetteter
Systeme geschaffen worden und hier kann sie ihre Vorzüge voll
ausspielen.

Bascom finde ich übrigens ganz ok, jedenfalls besser als dieser
AVRgcc-Bastelkasten, wo man sich jedesmal stundenlang mit neuen
Makefile-Konzepten und anderen ominösen Tools beschäftigen muß bevor
man auch nur eine einzige Codezeile zum Laufen gebracht hat.

Gruß, Norbert

Autor: Daniel R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Simon Küppers

>Ich
>persönlich höre Metal, und der geneigte Metal-fan kennt die
>Metal'schen Regeln: Andere Musik zwar nicht gut finden, aber nicht
>gegen sie vorgehen oder sie beschimpfen.

 [OT]
Hervorragend. Mir geht’s genau so.  ;)
Ich hab mal irgendwo hier im Forum gelesen, du seiest erst 16 oder
17...
Wenn das der Fall ist, würde ich gern mal ein bisschen mit Dir
plaudern.
Bin auch erst 17. Man findet nicht viele in diesem Alter, die was mit
Elektronik zu tun haben.
Hast Du ICQ?
...
[/OT]

Noch zum eigentlichen Thema:
Ich programmiere auschließlich in ASM(bin aber gerade am Erlernen von
C).
Ich finde wenns im Hobbybereich mal schnell was kleines zu proggen gibt
kann man das schon mal in C machen. Wenns aber schnell und *selbst
entwickelt* sein soll, bevorzuge ich ASM. Mir geht es bei meinen
Projekten hauptsächlich darum alles selbst zu entwickeln. Wenn man
dann C nimmt betrügt man sich selbst  ;)

Im Beruf, wenn es darum geht möglichst schnell ein Projekt
fertigzubekommen, ist ASM natürlich untauglich. Es dauert zu lang
usw.....Das versteht sich ja von selbst.


Trotzdem wird ASM wohl immer meine Lieblingssprache sein.

Bascom halte ich persönlich aber für Käse. Nur wer mit Hardware nichts
zu tun haben will sollte Bascom benutzten. Aber jeder wie er will :)


Daniel

Autor: neuer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich finde wenns im Hobbybereich mal schnell was kleines zu proggen gibt
kann man das schon mal in C machen....


ich glaube du kennst dich mit c noch nicht so aus, weil du so eine
total falsche aussage machst. c geht nicht eben mal schnell..he...bei c
muss du die datenblätter ordentlich lesen..he..he..ich glaube nicht das
du in asm so gut bist um die routinen von c nach da umzusetzen.
wenn du von winavr-c den umgestzten avr-code siehst, bist du zu 97% an
asm dran. schau dir mal den code an.
beschäftige dich jetz mal mit c.

Autor: neuer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wenn du auf asm sitzenbleiben tust, verpennst du den programmfortschritt
und kannst kein einziges wort in der entwicklung von programmen
mitreden... geschweige denn in dieser brache einen beruf zu dinden.

Autor: Daniel R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aufgepasst:
Wenn ich in C einen per UART was an den PC senden will habe ich 3 oder
4 Zeilen Initialisierungszeugs und genau eine Zeile für das Senden:
printf("\n\rtext\n\r");

Muss ich dazu ein Datenblatt lesen?
Ich nicht. Wenn Du das musst dann kennst nämlich Du dich nicht aus.

Autor: Εrnst B✶ (ernst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Daniel:

Ich geb Dir also nen uC, sag dir nicht welchen, geb Dir auch kein
Datenblatt, nur nen C-Compiler, und du schreibst 4 Zeilen
initialisierungscode damit printf auf irgendeiner seriellen
Schnittstelle funktioniert? Wow.

Das musst du mir mal erklären, hätt hier noch ein paar Tinys ohne UART,
da wär so eine 4 Zeilen Software Emulation schon was schönes.

/Ernst

Autor: Andreas Lang (andreas) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meiner Meinung nach ist es schlichtweg Wurst, ob nun BASCOM oder C.
Zum Ergebnis kommt man in beiden Fällen und wenn man BASCOM richtig
verwendet und kennt ist zwischen den Binaries praktisch auch kein
Unterschied mehr. Was für den schlechten Ruf von BASCOM sorgt sind wohl
die Leute, die denken, dass man sich in BASIC um nichts zu kümmern
braucht. Stimmt ja eigentlich auch, nur ist das Ergebnis halt ziemlich
Banane. Wenn man es richtig machen will, kommt man aber auch hier nicht
um die Datenblätter rum. Ich habe, als ich noch in BASCOM geproggt habe,
genausolange in den Datenblättern gewühlt wie heute mit GCC. Auf C bin
ich letztlich nicht umgestiegen, weil ich es so ultratoll gefunden
habe, sondern z.B. weil es mit BASCOM ein Krampf ist wirklich große
Projekte zu implementieren. Auch die Möglichkeit mit Klassen zu
arbeiten war ein Grund für C (macht auch Sinn, sogar aufm AVR).
Wenn ich nur mal schnell was Testen will nehme ich auch heute manchmal
noch BASCOM (um zu gucken, ob die hardware OK ist z.B.). Allerdings ist
BASCOM halt ein Windoof Programm. Und da ich nicht vorhabe BASCOM unter
Wine laufen zu lassen, verwende ich es seit meinem Umstieg auf Linux
halt praktisch gar nicht mehr.

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch wenn es nicht wirklich das Totschlagargument ist, so hat C den
Vorteil dass man wenn man es einmal gelernt hat nicht nur µC damit
programmieren kann. In C kann ich Programme auf Controllern, Windows
und Linux und was es sonst noch gibt schreiben.
Bei Basic lern ich erst BASCOM für den Controller, dann noch
VisualBasic, QBasic etc. auf dem Windows-Rechner. Und wenn MS da in den
Sinn kommt eine neue Version rauszubringen kann man das gelernte auch
wieder vergessen.
Dann lieber C lernen, auch wenn man am Anfang etwas mehr Zeit
investieren muss.

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich finde C super.

Man kann damit prima eigene Funktionsbibliotheken schreiben und die in
verschiedensten Projekten weiter zu verwenden.
Die Verwendung von Pointern und Strukturen macht das Programmieren
besonders flexibel.

Es gibt nichts, was in C nicht geht.

Z.B. ob sowas hier in Basic überhaupt möglich ist, würde mich mal
interessieren:

http://www.mikrocontroller.net/attachment.php/3134...


Peter

Autor: Daniel R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Ernst Bachmann

Ich wollte damit nicht sagen, dass man das Datenblatt gar nicht
braucht. Das ist ja auch Quark...
Natürlich muss man schauen, was der AVR hat/kann usw. Aber ich setzte
das beim oberen Post voraus.
Datenblätter "odrentlich lesen" ist für mich was anderes, als zu
schauen, ob der AVR oder irgend ein anderer uC einen UART hat oder
nicht.

@Peter Dannegger

Ich finde C mit der Zeit auch immer besser  :)
Aber ich kann mich einfach nicht von ASM trennen.

Daniel

Autor: Marko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also Ehrlich, ich persönlich arbeite in Bascom.
Der Grund:
Ich hab noch was anderes zu tun, die AVR sind hobby für mich
und wenn ich am Abend 3-4 Stunden an nem Projekt tüfteln
kann geh ich den nächsten Tag viel motivierter wieder drann
wenn ich n Ergebnis gesehen hab.
Das erreiche ich am Besten in Basic.
(Das hab ich halt noch vom c64 drinne)
Wenn dann meine Hardware in Basic läuft gehts ans Optimieren
und da ist für mich Bascom super. Ich kann nämlich
einfach ASM-Blöcke zwischen die Bascom Zeilen
einbauen um bestimmte Funktionen flotter machen zu können
und danach mit Bascom gemütlich ne Fließkommavariable
zu berechnen.
Danach kann ich wieder direkt auf Flags oder Register
per ASM zugreifen. Das tolle für mich ist,
ich kann erstmal alles in basic realisieren
und dann anschließend in einzelschritten den
Code straffen.
auf diese Weise hab ich schon mal nach der Optimierung
20% Flash eingespart.
Wenn man aber so vorgeht kommt man wie in C nicht am
Datenblatt vorbei.

C hab ich mal einzusteigen probiert und habs dann wieder
sein gelassen, weil mir die Syntax einfach nicht
gefallen wollte (obwohl PHP nicht ganz unähnlich, das ich für
andere Bereiche nutze).

Der einzige wirkliche Grund für Mich da wieder einzusteigen
ist eben die Universalität von C ... aber evtl. bastelt
ja mal jemand n Basic-Compiler für ARMs :o))

Autor: Daniel R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist ja auch völlig ok...
Nur ich möchte halt ganz genau wissen, was mein AVR macht und wie er
funktioniert. Das sind wichtige Grundlagen(und mir machen sie viel
Spaß).

Autor: Marko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich stimme dir zu dass es wichtig ist zu wissen was der so treibt,
aber ich hab da noch ne geschichte auf lager.

ein verwandter von mir macht zz seinen techniker in kaiserslautern.
für sein prüfungsprojekt muss er was mit avr machen.
der kleine hat auch die einstellung von wegen
eintauchen bis ins letzte bit ... der effekt ist,
er hat mit seinem asm schon mal 2 wochen gebraucht um
die twi in gang zu bringen (und er ist ansich nicht doof)

der endeffekt ist, das er in 6 wochen sein projekt vorstellen
muss und die bekackte schrittmotorsteuerung die er zu fertigen
hat, für nen kreuztisch, wird bis dahin nichtmal annähernd
betriebsbereit sein.

in bascom oder c hätt der kerl das in 2 wochen locker durchgezogen,
aber immerhin kennt er nun die register des avr auswendig und
ist mit jedem bit auf du ... danke, dann etwas mehr dirty.

in bascom hab ich in 3 wochen inklusive hardwaredesign
platinen ätzen usw. eine komplette regelung für meine
weinlagertanks gebastelt, komplett mit terminalsoftware
und visualisierung in php auf apache server ... da lob ich
mir doch die "hochsprachen"

Autor: Andreas Lang (andreas) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Trick ist ja an sich der, dass man den ASM immer dann nimmt, wenn
man etwas kleines schnelles braucht (z.B. Software PWM, da wäre es ja
irgendwie käse, wenn man da zig Takte für verschenkt). Das Drum herum
bastelt man sich aber am besten in C oder BASIC. Sonst wird es dann
irgendwann zur Qual.

Autor: Stefan Frings (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
printf entspricht nicht dem PRINT von Basic, es ist viel Mächtiger. In 
der Doku zur avr-libc kannst du nachlesen, wie du den Funktionsumfang 
von printf reduzierst (z.B. auf AUsgabe von Fließkommazahlen verzichten) 
und dann wird dessen Code auch viel kleiner.

Schau Dir mal puts() an, das wäre eher der richtige Befehl, um einfach 
nur Text auszugeben. Puts braucht auch nur wenige Bytes Speicher.

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

Bewertung
0 lesenswert
nicht lesenswert
Der Thread ist 6(!) Jahre alt.
Bitte nicht so himmelalte Schinken ausgraben.

Dieser Beitrag ist gesperrt und kann nicht beantwortet werden.