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 User
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
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
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
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.
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.
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 ...
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'
@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.
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.
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
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.
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:
1 | void uart_puts(*s) |
2 | {
|
3 | while(*s) |
4 | {
|
5 | while(UDRE..); |
6 | UDR = *s; |
7 | s++; |
8 | }
|
9 | }
|
(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)
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!
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...
@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.
@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ß
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
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
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...
@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ß
@ 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.
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.
"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
@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ß
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.
@pet: Wie groß wird denn der Code, wenn du das gleiche Programm in ASM schreibst? ...
@ Marc Meise Schlechten bzw. großen Code mit Rechenpower zu kompensieren finde ich aber auch nicht den richtigen Weg.
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.
> 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... ...
@
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.
@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
"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
und in den deutschen foren keine oder wenig hilfe von den beiden letztgenannten. castle
"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
"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
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
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
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.
> 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. ...
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
@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]
> OT
Scheen, ich freu mich für dich... Ist es denn in deiner Heimat (bei den
Sprotten)?
...
ja, und ich kann sogar (wenn ich meinen Kopf dolle verdrehe) auf den Kanal gucken...
@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
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.
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
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... .. .
@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.
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.
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.
klar ist sie ewffizienter: Sie kann wesentlich mehr bei nicht wesentlich mehr Code...
Ja, sie kann mehr, ist ja auch viel umfangreicher. Ich will doch gar nicht darüber streiten was nun besser ist :)
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...
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 :)
@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
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.
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
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... ;-)
>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...
@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
@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"...
@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
@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
@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 gehts 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
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.
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.
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.
@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
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.
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.
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/313478/flasher.zip Peter
@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
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))
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ß).
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"
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.
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.
Thread beobachten
Seitenaufteilung abschalten