Nokia LCD 3310+FastAvr

BASIC bedeutet 'Beginners All-purpose Symbolic Instruction Code', das 
erste Wort ist relevant. BASIC hat aus meiner Sicht einen 
Schwachsinnigen Syntax, von der Macht der Sprache C jetzt mal ganz zu 
schweigen. C ist zudem optimiert für systemnahe Programmierung, daher 
sind C-Befehle idr. sehr kurz und bündig in Assembler zu übersetzen.

Nicht jeder 'Programmierer' programmiert nach dem Bauklötzchenverfahren, 
und nur Code den man selbst geschrieben hat durchblickt man auch zu 
100%. Man braucht nicht für jede Kleinigkeit eine Megalösung, manchmal 
reicht 1/10 dessen was die vorgefertigte Funktion bietet, der Rest ist 
verschwendete Rechenleistung bzw. Speicher.

Bequemlichkeit hat noch nie zum Erfolg geführt, das gilt auch in 
Hinsicht Forensuche.

http://www.mikrocontroller.net/forum/forum.php?action=search&forum=1

hehehehe das mit der bequemlichkeit und dem erfolg und der forensuche 
mag ich sehr, sasha :)))

ansonsten hast du natürlich recht, wollte keine endlosen disskusion 
anfangen, einfach ein bisschen luft rauslassen; wir lieben doch alle die 
bequemen sachen, oder benutzt du nicht ab und zu den schlimmen windows 
statt den guten linux?

nicht böse sein, war nur eine denkanregung, keine kriegserklärung; 
natürlich hast du recht

emil

Hi

IO-Routinen schreibt man einmal selber (dann weiß man was sie tun) mit 
einem vernünftigen HAL und kann sie dann wieder und wieder verwenden. 
Man baut sich so seine eigene Codebasis. Außerdem kann man mit Basic 
nicht struktoriert programmieren. Ich denke da mit Grausen an VB das ich 
hin und wieder verwenden muß. Aber jedem das Seine.

Matthias

ja, habt doch beide recht, ich meinte nur: wieso inkludiert man nicht 
gleich so verbreitete sachen wie lcds, ir remotes, i2c mit in den 
application wizards oder wie immer sie heissen in c compilern;

das mach doch wirklich keinen sinn, heutzutage alles ganz von null 
anzufangen; ihr habt euer betriebssystem (mag es win oder linux oder dos 
sein) auch nicht selbst geschrieben, alle io- und graphic-routines 
drinnen nehmt ihr doch als gegebenheit und schafft etwas neues und 
sinnvolles, so muss es halt sein;

oder glaubt ihr,  der herr anreas schwarz z.b. konnte dieses forum  als 
(zitat copyright sasha) ein "echter 'Programmierer'" nicht "nach dem 
Bauklötzchenverfahren", sondern von nullanfangend, in 
platformunabhängiger maschinensprache verfassen...

das errinert mich irgenwie an ein programm für pizzeriamanagement, (vor 
11 Jahren); damal habe ich die grafische oberfläche  pixel für pixel und 
linie für linie gezeichnet, hat 2 monate gedauert; jetzt schafft ein 
16-jährige bursche eine viel schönere oberfläche mit vc++ für 20 min...

ich würde wohl nicht behaupten, das der 16-jährige bursche blöder ist 
als ich, weil er die registergeheimnisse des grafikkartenkontrollers 
nicht kennt, ganz im gegenteil, pech für mich, das ich so viel zeit für 
low-level aufgaben verschwenden musste...

Wie Matthias schon gesagt hat, man baut sich Stück für Stück seine 
eigene Codebase auf... damit hats sich! Es ist einfach ein Irrglaube 
sich irgendwo aus dem Netz eine Funktion ziehen zu können die man auch 
wirklich anwenden will. Wenn dann muss man sie vorher gründlich 
studieren und wahrscheinlich auch anpassen, da nehm ich mir doch lieber 
die 10 Minuten die entsprechende Funktion selbst zu überdenken und zu 
schreiben, völlig konform mit meinem standard Programmierstil.

Und wenn ich das wirklich sehr böse Wort 'Wizard' höre kommen mir graue 
Haare, niemand ist auf so etwas wie 'vorausgefüllte' Programme 
angewiesen. Ich habe mein Arbeits-OS nicht programmiert, also hinkt der 
Vergleich mit eigenentwicklungen wirklich sehr... und natürlich basiert 
jedes ernstzunehmende OS auf einen plattformspezifischen Code, für 
möglichst viele Plattformen, von Null auf gewachsen.

Es gibt nichts schlimmeres als ein Bauklötzchenprogramm... soetwas kann 
wirklich jeder 16 jährige, obwohl ich garnichts davon halte einen 
Menschen anhand einer Zahl einzuschätzen, in den PC hacken. Ein 
zukünftiges Programm strukturiert zu planen erfordert hingegen etwas was 
man wirklich als 'programmieren' bezeichnen kann.

Und das ganz egal ob C, C++, C#, ASM, BASIC, Pascal, Objective Pascal, 
Cobol, oder was weiss ich alles... Ohne Planung kommt bei größeren 
Projekten nichts sinnvolles heraus. Mit Planung hingegen ist man auf 
Bauklötzchen nur noch in Routineaktionen angewiesen, und selbst diese 
sind dann höchstwahrscheinlich selbstentwickelt.

Sascha, stell dir vor du nimmst Bauklötzchen und programmierst daraus 
strukturiert eine neue Software. Das ist nicht böse oder verwerflich, 
das ist der Lauf der Evolution.


Oder weisst du (noch) genau was im Innern des µCs vorgeht? Könntest du 
ein Rechenwerk, Steuerwerk... diskret aufbauen? Wieviel Prozent der 
Chipfläche/Hardwareresourcen verschenkst du bei jedem eingesetzen µC?

Diese Basic/Pascal...-Programmiersprachen sind (so wie man liest) 
momentan praktischer und in punkto mitgelieferter Bibliotheken den guten 
alten C-Compilatoren :) überlegen.

Schmittchen.

leute, es ist doch fr. abend, lasst uns einfach 'paar bier trinken :))) 
sasha hat recht, schmittchen auch und ich sowieso und mattias:)))

@sasha: sehr gute ausdrucksweise, kompliment!!!, ist ziemlich selten 
unter leuten, die mit technik zu tun haben; unterrichtest du vielleicht 
an der uni?

@schmittchen: schöner nick, heisst das "der kleine schmidt"? :)))

übrigens, apropo pascal; avrco ist wirklich umwerfend, strukturierte 
sprache + umfanreiche bibliotheken (alles, was sonst bei basic gibt, 
i2c, lcd usw). wirklich schade, dass er so teuer ist :(((

und ich wusste gar nicht, das "c" für militär-, medizinische und 
aerospace anwendungen verboten ist (steht auf der seine von 
www.e-lab.de, die avrco macher, habe ich nicht erfunden)

wollte keine so grosse diskusion anfangen, sondern nur die vielen leute 
erfreuen, die interesse an nokia lcd gezeigt haben, vielleicht kann 
jemand doch noch was mit fastavr anfangen, das einzige bisher 
funktionierende steuerprogramm diesbezüglich wurde (ratet) mal auf 
pascal geschrieben mit eben avrco, glaube ich; wer hat sie gepostet, 
habe schon vergessen, sie ist sogar auf dem e-lab forum...

in diesem sinne: bier nur strukturiert und nicht "bauklötzchenweise" 
übers wochenende trinken!!!

emil

Da sieht man mal wieder wie unterschiedlich doch die Anforderungen 
einzelner Leute sind. Ich gehöre auch eher zu der Fraktion die sich 
lieber mit der Applikation befassen als für jeden Krempel erstmal eine 
Lib schreiben zu müssen. Das ist vor allem dann interessant wenn man 
damit auch mal Geld verdienen will. Wenn ich mir überlege das ich meine 
letzte Applikation mit dem AVR GCC hätte erstellen müssen...
Ich wäre heute noch nicht damit fertig

@emil: ich verwende den AVRco, ich habe im gesamten µC Bereich noch 
nichts vergleichbares gesehen. Mit dem Preis hast Du recht, aber er ist 
so gesehen jeden Cent wert. Und der Support ist absolute spitzenklasse. 
Wenn man einen Bug findet ist der manchmal innerhalb einer Stunde 
behoben, maximal nach einem Tag. Sogar manche 
Änderungswünsche/vorschläge wurden schon innerhalb eines Tages erledigt. 
Ich bezweifle stark das man sowas bei AVR GCC & co hat
Vom AVRco gibt es eine Demo die immerhin 4kB kompilieren kann, alle 
anderen sind auf 2kB begrenzt. Für den Mega8 gibt es eine Version für 25 
Euro. Kann zwar nur für den Mega8 Programme erstellen, dafür aber alle 
8kB Speicher nutzen.
Gibts aber nur bei www.embedit.de

Ach ja, und C ist wirklich nicht für die genannten Bereiche erlaubt. Es 
ist einfach zu fehleranfällig (Stichwort Pointergrab) und 
wartungsintensiv, Jetzt mag er eine ider andere denken, ja Linux ist 
doch auch in C geschrieben und läuft stabil, aber Linux läuft seit 
etlichen Jahren auf etlichen Rechnern etliche Stunden am Tag. Da hat man 
genügend Zeit um auftretende Fehler zu entdecken. Beim Militär, in der 
Medizin und erst recht in der Raumfahrt ist die Anzahl der Geräte und 
die Laufzeit extrem klein, zu klein um mit Sicherheit alle Fehler zu 
finden.

Mal wieder Glaubenskrieg angesagt?
Na ja ist beinehae Vollmond - also mach ich mal mit.
Ein Nokia LCD 3310+FastAvr werde ich wohl kaum einsetzen (Nokia sind 
doch die, die ihre LCD's nicht mal bei ihren eigenen Handys 
zuverlässlich zum Laufen bringen). FastAvr Ist aber schonn 
beieindruckend was die alle können wollen... Ich will aber nicht nur 
können wollen, sondern verstehen was ich mache. Wizard sind auch mir 
(Gruß an Sascha) ein absoluter Greul... Denn sie wissen nicht was Sie 
tun (viel schlimmer noch, ich weiss es auch nicht). Ich möchte gern 
Hardwarenahe programmieren ohne beim nächsten Wechsel auf einen anderen 
uC alles wegschmeissen zu muessen also nehme ich C. WINAVR ist 
kostenlos. Motorola bietet fuer ihre neuen FlashContoller (30 Mips - low 
budget) aber auch C-tool's fuer low an. - Und wenn schon bequem dann 
AVRCO - ist wenigstens ne' Hochsprache die einem zum diszipliniertem 
Programmieren zwingt.
Gruß Bernhard

Hi Bernhard,
jaja, die Glaubenskriege, so sinnlos und unvermeidlich wie ein echter 
Krieg :)
Aber das mit dem Displays versteh ich nicht. Wieso sollen die die 
Displays nicht zum Laufen bekommen? Gibts da Probleme? Wenn ja dann 
vermute ich mal das es nicht an den Displays selbst liegt. Das läuft bei 
mir schon seit ner Weile problemlos
Gruß
Markus

@ Emil ,
kann dir voll und ganz Recht geben.
Verwende Bascom und bin voll damit zufrieden.
Dass man sich als Basic-Verwender hier nicht allzu
beliebt macht hab ich schon bemerkt.
Aber gerade als Einsteiger zählt auch mal das rasche
Erfolgserlebnis.

Gruss Gerhard

morgen!

jo jo, markus, GENAU DAS habe ich mir ürsprünglich gedacht, als ich hier 
über FastAVR gepostet habe:

(das hier ist vom original-nokia3310-lcd-thread):
(zitat copyright Markus):"Mittlerweile hab ich es sogar geschafft die 
Grafik Library vom E-Lab Pascal Compiler so anzupassen das es mit den 
Nokia Disolay läuft :)
Jetzt brauche ich keine eigenen Grafik und Text Routinen zu schreiben. 
Leider gibts die Grafik Library nur in der Profi Version"

NA EBEN: wer einen guten compiler mit eingebauten features zur verfügung 
hat, brigt schnell was zum laufen und geht danach bier ttrinken; die 
anderen beisen immer noch in den grünen zweig...

ich meine, hauptsache das ding kommt zum laufen, dann kommt hoffnung 
zurück; wer jetzt ein profi wie sasha ist, der kann sich die sache noch 
einmal gründlich anschauen und vielleicht noch besser machen;respekt!

wer dagegen wie ich eher auf anderen bereichen profiliert ist, der sagt 
sich nun: " ok, das war eine richtige denkweise überhaupt, keine 
verschwendete zeit, jetzt kaufe ich vielleicht einen grösseren atmel, 
denn der kompiler hat ein wenig codeüberschuss, aber es ist doch nicht 
so teuer und ich bin happy, es geht doch"

eben das habe ich mit dem posting gemeint; die letzte version von 
fastavr ist erst seit 5 tagen online, die leute kennen sie noch nicht;

bin in keiner weise mit jemanden von fastavr-machern verwandt oder so 
und mache keine werbung

@Schmittchen: Ok, solange jedes Bauklötzchen funktioniert wie es soll... 
Den internen Legosteinchen von Atmel vertraue ich diesbezüglich aber 
komplett ;)

@emil: Danke für das Kompliment mit der Ausdrucksweise, aber vom 
Uni-Dozenten bin ich zum Glück noch meilenweit entfernt :)
Die Erfolgserlebnisse sind was verdammt wichtiges. Nur so macht es auf 
dauer Spass, und solange es sich 'nur' um ein Hobby handelt ist dies 
doch das wichtigste!

Um nochmal etwas zum Thema beizutragen, solange alles so klappt wie man 
es auch will ist doch jeder Compiler recht. Der eine bevorzugt halt C, 
der andere BASIC und ein dritter kommt dann noch mit Pascal daher. Bei 
z.B. militärischen System braucht man auch kein C, dort gibt es andere 
machtvolle Sprachen wie ADA. Aber gerade bei den AVRs, die sehr viel 
On-Chip Peripherie haben, sind vorgefertigte Funktionen relativ 
überflüssig, die meisten Angelegenheiten sind nicht viel mehr als ein 
paar Bits in den Registern zu setzen. Softwareemlulation von z.B. Bussen 
übernehme ich dann wiederum lieber selbt, denn, traue keinem! Hehe

viva los ansi c

naja ich bin doch noch für cpp... scheiss vc++...da gewöhnt man sich das 
lustige oop so schnell an und darf dann doch ansi c programmieren... 
anderseits hat man dafür leider nicht den speicher...trotz mega32 ;)

naja auf jeden fall ist c das einzig wahre... ich verwende hin und 
wieder auch das bascom avr...nur damit werd ich bei komplexeren sachen 
ned glücklich...

und das mit dem selbstschrieben...wieviel arbeit machts wirklich ne 
lcd-lib für den hd44irgendwas zu machen ? ;)

und i2c muss ich mir am mega32 noch genauer anschaun...is aber 
anscheinend ned wirklich kompliziert so wie ichs seh..uart sind 20 
zeilen..bei mir 50 weil ich alles über ints machen lass....

wizards sucken zu 90% weil sie ja nicht wissen was man will...

die spucken immer code aus den man garned haben will...

ist das gleiche wie beim libc von gccavr... sprintf als ganzes 
reinkompiliert braucht so viel speicher das es überhaupt unsinnig 
ist...da arbeite ich lieber mit fixed-point arithmetik und selfmade 
string routinen...ist 1. lustiger und 2. kleiner und damit auch 
schneller G

im endeffekt hängt alles davon ab was man machen will... es gibt keine 
sprache die perfekt ist ;)

in diesem sinne 73 HG

Anscheinend wissen einige nicht was die Wizzards eigentlich machen. 
Zumindest beim AVRco macht der nichts anderes als ein Grundgerüst für 
ein Projekt zu erstellen. Was man für das Projekt braucht muß man 
natürlich selbst wissen. Und überflüssigen Code erzeugt der Wizard 
nicht.
Und die Erstellung von Funktionsbiblioteken ist nicht mein Ding. An 
einer Lib für ein HD44780, die alle möglichen Funktionen unterstützt und 
dann auch noch solche Funktionen wie writestring  usw kann würde ich ne 
weile knabbern. Desshalb bin ich mit dem AVRco vollkommen zufrieden. Da 
weiß ich das alle Lib's in ASM geschrieben sind und ich kann davon 
ausgehen das die funktionieren.
An solche Sachen wie eine Grafiklibrary oder gar FAT16, TCP/IP und 
ähnliche Sachen will ich mich erst gar nicht ranwagen, selbst wenn es 
dafür schon von anderen funktionsfähige sourcen gibt.
Aber wie schon gesagt, jedem das Seine :)