Effizienz von Bascom !?

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

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

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

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

daumenhochhalt na so langsam Gewinn ich doch n bisschen Vertrauen in 
die AVRs g

> 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.