Hi Da ich eigentlich in Sachen AVR Neueinsteiger bin und auch nicht gerade ein großer Fan von Assembler solange es noch anders geht hab ich mir überlegt hauptsächlich mit Bascom zu arbeiten. Basic - da kommt C64-Feeling auf grinz Wollte nur mal fragen ob zufällig jemand weiß wie effizient der Compiler arbeitet - d.h. wieviele Prozent an Speicher usw ich gegenüber der Assemblerprogrammierung verlieren würde ?! THX Chris
Hallo, bin auch Einsteiger, habe auch keine Lust auf ASM, habe mit C-Control gearbeitet, ich möchte FASTAVR nutzen, soll sehr guten kleinen Quellcoder erzeugen, download DEMO unter www.FASTAVR.com. Vorteil, es gibt viele Assistenten, z.B. Text auf Diplay mit 4 Programmzeilen !!! Wenn du damit arbeiten möchtest, könnten wir uns mal zusammentun' Gruss Alex
mhhhh - FASTAVR hört sich im ersten Moment an wie reine grafische Programmierung. Falls du den Thread "midi-Application" gelesen hast wirst du bemerkt haben haben, daß das wahrscheinlich mit solchen Mitteln nicht programmierbar ist. Aber vielleicht irre ich mich ja - werds mir auf jeden Fall mal ansehen. Grüße Chris
Also, ich hab noch nie mit BASCOM gearbeitet, aber erfahrungsgemäß gibt C deutlich bessere Ergebnisse, wenns unm Geschwindigkeit und Effizienz geht!
Hatte in nem anderen Posting mitbekommen, daß der C-Compiler für die AVRs nicht gerade den saubersten Code erzeugen soll - wesentlich schlechter als der C-Compiler für PIC. Aber wenn das gut funktioniert wieso nicht - denkst du C ist für mich schwer zu erlernen (kann bereits Basic 2.0, 7.0, bisschen qbasic, bisschen vbasic, bisschen Perl, php, JavaScript) oder ist C komplett anders aufgebaut ? Grüße Chris
Naja, C ist schon ziemlich anders als Basic. Syntaxmäßig wirds dich an Java erinnern, aber es wird schon ein ziemlicher Brocken zu lernen sein - als Stichwort mal Pointer usw. Aber für die µP/µC-Entwicklung ist C (nach Assembler) meiner Meinung nach die beste Sprache. Da es fast unmöglich ist, größere Projekte in Assembler zu realisieren wird das meiste eigentlich in C gemacht.
In Sachen programmiersprachen lernen bin ich relativ abgehärtet g ... das klappt schon. Nur noch eine Frage: Kennt jemand ne ordentliche Referenz (Ob im Net oder Buch ist egal) aus der man lernen kann? Ne große Umschreibung von Objekten oder Variablentypen muß nicht sein - denke das ist z.B. bei JavaScript ähnlich (zumindest was Objekte angeht)... nur n bisschen Grundwissen, Befehle - am Besten Beispiele dazu. Grüße Chris
AVR-GCC erzeugt sehr guten Code. Im Gegensatz zum PIC wurde die AVR-Architektur sogar speziell zur Verwendung mit C entwickelt. Für mein Midi-Projekt wollte ich am Anfang auch Bascom verwenden, aber ich habe es in mehreren Stunden nicht geschafft meinem CS1x ein "Note on" zu senden. Bis ich erst mal rausgefunden hatte welche von den 10 UART-Funktionen überhaupt für das senden von binären Daten geeignet ist... hab dann irgendwann wegen verschiedenen Bascom-Bugs aufgegeben und bin auf C umgestiegen. Innerhalb von einer halben Stunde lief es. Ich finde Basic ist im Vergleich zu C eine völlig unlogische Sprache. Allein schon wegen der völlig sinnlosen Unterscheidung zwischen Subs und Functions... In C muss man nur mal ein paar Grundkonstruktionen verstanden haben, dann kann man alles machen.
OK - hab mir gerade den kompletten Artikel hier von der Site über C reingezogen und muß sagen C sieht aus wie die Möglichkeiten ein paar anderer Sprachen zusammengewürfelt - also Glücklicherweise nicht allzuviel neues. Angenommen ich würde jetzt C lernen ... wie setze ich dann die Befehle, die ja eigentlich für Bildschirmausgaben usw sind für einen AVR um ? Ich meine sind die speziellen Befehle um z.B. irgendwas an Port C auszugeben irgendwo dokumentiert wo ich mir das mal ansehen könnte ? THX Chris
Hallo Leute, was ist besser, was ist schlechter - ist wie mit den Autofahrern: jeder schwört auf seine Marke die er gerade fährt..., und die ist natürlich die beste Marke! Konkret gibt es da so'n Geschwindigskeits-Test zwischen verschiedenen Compilern (Elektor Heft 5, Mai 2002). Eine einfache FOR-NEXT-Schleife z.B. in Bascom-51 braucht < 2K ROM Speicher und 30 µs Schleifenzeit. Assembler < 1K ROM und 3 µs. Der READS51 C immerhin >4K ROM,RAM und 125 µs Schleifenzeit. Ich persönlich halte das BASIC immer noch für eine hervorragende Programmiersprache (vielleicht weil ich zu den Bödis gehöre?) bis
Hallo Chris, ich hab auch vor kurzem einige Compiler Demos ausprobiert. Mein Favorit war der ELAB Pascal (der leider sehr viel Geld kosten). Am Ende habe Ich mich eindeutig dafür entschieden GCC zu lernen. Hier gibt es genügend Freaks die einem helfen. Man braucht meist gar keine Fragen stellen - Ist alles schon mal gefragt worden (siehe Forum AVR-GCC). GCC kriegst du zudem kostenlos (siehe Auf diesen Seiten unter AVR-GCC). Christian aus der Schweiz war auch gerade so nett eine Einführung in C zu schreiben (unter Artikel). Gruß Bernhard
Genau den Artikel hab ich mir ja durchgelesen ;) Also der Speicherverbrauch und die Bearbeitungszeit bei dem GCC macht mir schon ein bisschen Angst. Besonders @ Bernhard: Du hast ja mitbekommen um was es bei dem Midi-Sequenzer geht. 64 Tastenzustände auslesen, 64 LEDs schalten, LCD ansteuern, Midi-Clock + Midisignal in Abhängigkeit von der vorgegebenen Geschwindigkeit erzeugen (Bpm) und eben noch die ein oder andere Funktion wie das Umschalten im Betrieb auf eine andere Speicherbank. Jeder ist davon überzeugt das packt ein AVR ohne Probleme - aber wenn ich mir den Vergleich so ansehe programmiert man entweder alles in Assembler oder man lässt es gleich. Soll das ein einziger Prozessor wirklich schaffen wenn er schon 125 µs für eine simple For ... Next - Schleife braucht ? mhhhhhhhh ... vielleicht ist Assemler ja wirklich das einzig vernünftige wenn es um Projekte geht wo das Timing wichtig ist ... Grüße Chris
In dem Vergleich geht es um 8051er, die Ergebnisse sind nicht auf AVR übertragbar. Eine leere "for"-Schleife in AVR-GCC braucht pro Durchlauf auf einem 8MHz-AVR ungefähr 1µS. Das kleine MIDI-Sequencer-Programm das ich dir schon gezeigt habe braucht 662 Bytes Flash. Und schau mal auf www.yampp.com. Ein kompletter MP3-Player mit Festplatte, LCD usw. in einem AT90S8515, programmiert mit AVR-GCC. Immer noch Zweifel?
OK - das wusste ich jetzt nicht - hab auch nicht gerade nachgerechnet ;) Nur wie ist das ca beim AVR im Verhältniss ... ich meine um ein wievielfaches ist denn Assembler da noch mal schneller ? Grüße Chris
Das kann man nicht so pauschal sagen, aber mit einem guten Compiler wird der Geschwindigkeitsunterschied kaum spürbar sein. Der Mehraufwand lohnt sich nicht. Glaub mir, bei deinem Projekt kommt es nicht auf Geschwindigkeit an. Der AVR wird 90% der Zeit Däumchen drehen.
na solang die Geschwindigkeit ausreicht soll mir das auch egal sein ob 10% oder 90% der Resourcen benutzt sind ;)
Für alle, die es noch nicht wussten. C ist nicht deshalb so schnell weil
es C ist, sondern deshalb, weil dieser Programmiersprache sämtliche
Laufzeitkontrollen (z.B. Prüfung von Felddeskriptorgrenzen oder Prüfung
von Typumwandlungen etc.) fehlen. Sowas beschleunigt schon ungemein!
> Eine leere "for"-Schleife in AVR-GCC braucht pro Durchlauf auf einem 8MHz-AVR
ungefähr 1µS.
Mit oder ohne eingeschaltetem Optimierungsflag? ;-)
Gruss,
Peter
Das ist ja das schöne an C: man kann machen was man will, ohne dass der Compiler dazwischenfunkt. Und alles schön einfach, keine Verrenkungen wie "substr(string,3,1)" nötig wenn man einfach nur das 3. Zeichen eines Strings haben möchte. Die Optimierung war beim for-Test eingeschaltet, aber ein nop im Schleifenkörper (sonst hätte sich wohl die Durchlaufzeit auf den konkurrenzlosen Wert 0 verringert ;-) )
> Für alle, die es noch nicht wussten. C ist nicht deshalb so schnell weil es C
ist, sondern deshalb, weil dieser Programmiersprache sämtliche Laufzeitkontrollen
(z.B. Prüfung von Felddeskriptorgrenzen oder Prüfung von Typumwandlungen etc.)
fehlen. Sowas beschleunigt schon ungemein!
Das ist ja der große Vorteil von C - wenn jemand ein Embedded System
programmiert dann sollte er eh wissen, was der µC machen soll, und dann
kann sich der Compiler schön im Hintergrund halten. C ist DESHALB so
schnell, weil es hardwarenahe ist, nicht umsonst kann man einfach mal
zwischendrin ein paar Assembler-Befehle einbauen :)...
Letztendlich ist es mir egal in welcher Programmiersprache eine Aufgabe gelöst wird, Hauptsache das Ganze funktioniert im Rahmen der Vorgaben. Über den zusätzlichen Overhead den ein Compiler produziert kann man endlos diskutieren. Teilweise ist hier natürlich der Programmierer nicht ganz unschuldig, indem er falsche Datentypen z.B. float anstelle von integer wählt wenn es nicht notwendig ist. Ebenso wird natürlich auch Zeit und Speicherplatz mit unnötig aktivierten Debug Optionen verschwendet. Ein Greuel sind mir persönlich die teilweise zwar sehr umfangreichen aber doch schlechten Dokumentation bei einigen Produkten. Hier gewinne ich immer mehr den Eindruck, Hauptsache viel aber das liest ja eh keiner. Daher will ich an dieser Stelle auch keine individuelle Wertung für oder gegen ein bestimmtes Produkt abgeben. Man sollte aber doch mal einen Blick auf die Dokumentation werfen, ob man Informationen die einem wichtig erscheinen oder auch notwendig sind, schnell findet bzw. überhaupt vorhanden sind. Evtl. kann man ja auch mal einen Blick auf den vom Compiler produzierten Code werfen. Aber das ist ja nicht jedermanns Sache, zumal wenn man den Assembler für einen Zielprozessor gänzlich meiden will.
Hi, ich versteh nicht, wieso alle immer nur von Basic und C reden. Es gibt noch andere Programmiersprachen wie z.B. Pascal. Es gibt einen hervoragenden Pascal Compiler von E-Lab (www.e-lab.de) der den Funktionsumfang von C bei weitem übertrifft. Oder ist beim AVRGCC sowas dabei wie Multitasking, eine LCD Lib, oder ein Multimasterfähiger I2C Bus? Teile davon gibt es sicher, aber die muß man erstmal einbinden und beherrschen. Dabei ist Pascal nur unwesentlich schwerer als Basic. Ich weiß, jetzt wird wieder jeder C Programmierer aufschreien, aber so ist es nun mal. Kurz gesagt, ne bessere Komination zwischen einfacher Programmiersprache und großem Leistungsumfang für den AVR kenne ich nicht. Und die Demoversion kann bis zu 4kB Code erzeugen, genug also, um den 4433 voll auszunutzen. Für den Mega8 biete ich eine Sonderversion, die den Speicher des Mega8 voll ausnutzt und sogar noch einen Bootloader Support bietet. Und das für nur 25,- Gruß Markus http://www.elektronik-projekt.de http://www.e-lab.de
Markus, du hast vergessen zu erwähnen wie Kompakt der compiliert. Ich habe mal aus Spaß ne Luftfeuchte Umrechnung mit Temperaturkompensation auf dem Simulator durchgespielt (Floatingpoint Berechnung satt) selbst mit LCD-Ausgabe noch weit unter der 4K Grenze. Bei der Taupunktberechnung war dann allerdings Sense. Ohne Frage ist der sein Geld wert, aber für einen Nichtprofi kaum finanzierbar. Wenn das Programm den 4K Rahmen sprengt kann man neu anfangen. Dazu kommt noch das Problem mit der Portierung (Pascalcompiler kommen meist recht spät auf den Markt). Der Hauptgrund wieso ich mich jetzt entschieden habe doch auf C zu gehen ist halt, das ich recht wenig umlernen muss, um auf einen andere Prozessor zu Programmieren. Die Mega8 Version würde mich allerdings interessieren. Was kommt den da an Nebenkosten dazu ?.
Wie groß der Code wird, hängt unter anderem davon ab, welche Librarys eingebunden werden. Auch wenn nur eine Funktion aus einer Lib gebraucht wird, binden manche Compiler die ganze Lib ein. Andere Hersteller versenken ellenlange Copyright-Strings in Ihren Libs, die auch jede Menge Platz fressen. Siegfried
Momentan sprechen ein paar Gründe trotzdem eher für C: 1) Beherrscht man diese Sprache erstmal ist es wahrscheinlich auch kein allzugroßer Schritt mehr zu C++ was für PC-Programmierung selber, was man ja auch mal hin und wieder gut gebrauchen kann, finde ich optimal ist. 2) Es gibt zu wenige die sich mit Pascal auskennen und wenn ich als Anfänger zum Beispiel mal das ein oder andere Problem habe - an wen soll ich mich da wenden? Gibt es für Pascal ein ordentliches (am Besten deutsches) Tutorial und eine Referenz? Grüße Chris
@ Siegfried: Bei dem Bascom kann man geziehlt einzelne Funktionen aus einer Lib einbinden. Effizienter geht es wohl kaum, wenn man nicht in ASM Programmiert und jede Funktion 100% anpasst. @ Bernhard T: Hast schon recht, die Vollversion ist teuer. Aber man bekommt auch ein Programmiergerät im Wert von 109 und ein gedrucktes Handbuch und was weiß ich was noch alles. Vielleich kann man mit denen Reden und zu einem vergünstigten Preis nur die Software bekommen. Aber die Leistung rechtfertigt den Preis. Und die "professionellen" C-Compiler von IAR & co sind noch teurer. Was die Aktualität angeht: der AVRco Pascal Compiler unterstützt ALLE AVR Controller, im Gegensatz zum AVR GCC, der in der Windowsversion gerade mal den Mega8 und Mega128 unterstützt, lange, nachdem der AVRco das konnte. Die Firma E-Lab hat da einen ganz anderen Stellenwert, weil sie an Controller rankommen bevor sie auf den Markt kommen. Die Entwickler des AVR GCC haben da einen Nachteil. Trotzdem Hut ab vor deren Leistungen Gruß Markus
Hallo Markus. Ich würde ELAB-Pascal nie als teuer bezeichnen. Mir fehlen nur die Mittel. Ich sage doch auch das mich die Mega8 Version für 25.- EURO Interessiert (ich stehe nicht auf Glaubenskriege- bevorzuge sowohl als auch :-). Eine abgespeckte Software pur währe natürlich auch toll. Kannst du mir vorab sagen was an Nebenkosten dazukommt wenn ich die bei dir bestelle. Gruß Bernhard
Also was Aktualität und Unterstützung von CPU angeht, muss ich teilweise herzhaft lachen. Außer dem Mega8 bzw. MEGA128 hat wohl noch keiner die ganzen angekündigten MEGAs als Serienprodukt gesehen. Es sind wohl einige Vorserienmuster zur Entwicklung an die verschiedenen Hardware- und Softwareentwickler rausgegangen. Was nutzen diese aber, wenn einige Funktionen nicht korrekt funktionieren und andere Eckdaten als "to be defined" gekennzeichnet werden. Habe leider auch den Fehler begangen schon im 1. Quartal für den Mega8535 für neue Projekte vorzusehen, muss aber nun leidlich feststellen das fester Liefertermin nicht in Aussicht ist.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.