Wer es noch nicht gesehn hat. Auf der Seite http://www.shop.robotikhardware.de/shop/catalog/news_zeigen.php?id_news=27 gibt einen interessanten AVR Wettbewerb. Wer sowieso was in der beschriebenen Richtung bastelt, könnte 500 Euro gewinnen. Da gewöhnlich recht wenige Teilnehmer bei solchen Wettbewerben mitmachen, ergibts sich sicherlich eine brauchbare Gewinnchance.
Bastler wrote: > Auf der Seite > http://www.shop.robotikhardware.de/shop/catalog/news_zeigen.php?id_news=27 > gibt einen interessanten AVR Wettbewerb. Die Software muss (zumindest teilweise) in BASCOM geschrieben sein, somit dürften die wirklich guten Projekte wegfallen. Selbst schuld wer solche dummen Regeln aufstellt.
gast wrote: > Die Software muss (zumindest teilweise) in BASCOM geschrieben sein, > somit dürften die wirklich guten Projekte wegfallen. Selbst schuld wer > solche dummen Regeln aufstellt. Das ist natürlich ein absolutes KO-Kriterium. Aber als MC sind alle Atmels zugelassen (8051, AVR, ARM7, AMR9, Cortex M3). Peter
Im Zusammenhang mit dem "leicht nachzubauen" finde ich diese Regel absolut begrüßenswert. Basic-Derivate sind im Vergleich zu C oder gar Assembler extrem leicht zu erlernen und insb. leicht zu verstehen, auch für Programmieranfänger. Das Ziel ist doch klar: Man möchte ein Projekt finden, prämieren und vorstellen, welches die breite Masse anspricht und nicht nur ein paar Freaks oder Leute die sich schon ewig damit beschäftigen. Gruß Dominique Görsch
@ Dominique > Das Ziel ist doch klar: Man möchte ein Projekt finden, prämieren und > vorstellen, welches die breite Masse anspricht und nicht nur ein paar > Freaks oder Leute die sich schon ewig damit beschäftigen. Und dann macht man eine Programmiersprache zur Grundbedingung für die man wenn überhaupt nur schwer eine Freeware-Entwicklungsumgebung finden kann?
>Die Software muss (zumindest teilweise) in BASCOM geschrieben sein,
Da kann man mal raten wer das Preisgeld gestiftet hat ;-)
Genau lesen. "Zumindest ein Beispielprogramm muss in Bascom-Basic beiliegen und einen Teil der Fähigkeiten demonstrieren." Also wer sowieso etwas in der Richtung entwickelt und nicht zu arrogant ist, um ein paar Zeilen Basic zusammenzubringen, für den ist das doch in Ordnung. Es zwingt ja nicht dazu, den gesamten Code in Basic zu schreiben.
ich zitiere: Mit der Einsendung erlaubst du die lizenzkostenfreie Veröffentlichung und den Nachbau und Ausbau des Projektes! Ebenfalls gestattest du die Veröffentlichung im Roboternetz.de oder auf der Robotikhardware CD. Ich sage einfach mal frech dass die damit Geld verdienen wollen. (zb.: mit bausätzen oder sowas....) Gruß Anselm
...der nächste Pollin Bausatz! Der Ansatz "für die breite Masse" beißt sich aber etwas mit BASCOM. Da wäre C sinnvoller.
Da bist du aber Fern von der Realität! Fast 70% der AVR Anwender verwenden Bascom. In meinem Bekanntenkreis sind es sogar 90% !
Du glaubst doch nicht wirklich, dass irgendwo in der Industrie mit BASCOM programmiert wird!?!
>Du glaubst doch nicht wirklich, dass irgendwo in der Industrie mit >BASCOM programmiert wird!?! Nein, das glaube ich nicht. Das weiß ich. gez. Katapulski
Ebenso werden ja auch große, produktive Anwendungen mit VB erstellt, obwohl es so verhasst ist. Gruß Dominique Görsch
Gast wrote:
> In meinem Bekanntenkreis sind es sogar 90% !
Wenn diese Aussage stimmen soll, hast Du also mindestens 10 Bekannte,
wovon 9 hauptberuflich mit Bascom programmieren.
Ich kann Dir sagen, das sämtliche Programmierer bei mir in der Firma zu
exakt 0% in Bascom/Basic programmieren.
Sondern hauptsächlich C/C++ und etwas Erlang/Java.
Peter
>das sämtliche Programmierer bei mir in der Firma...
Wieviele Programmierer gibt es bei Dir in der Firma außer Dir selbst?
;-)
SCNR
Katapulski
Katapulski wrote: >>das sämtliche Programmierer bei mir in der Firma... > Wieviele Programmierer gibt es bei Dir in der Firma außer Dir selbst? > ;-) 5 Programmierer und dann noch ich, der hauptsächlich Hardware entwickelt und nebenbei auch mal etwas dafür programmiert (MCs, CPLDs). Ich bin also gar kein richtiger Programmierer. Es ist ganz angenehm, selber entscheiden zu können, was besser in Hardware geht und was besser in Software. Anfangs, als ich nur Hardware gemacht habe, hat sich ein Programmierer geweigert (es sei zu kompliziert), ein Signal in Software zu invertieren und ich mußte einen Transistor mit Heißkleber auf das Board draufpappen lassen. Das passiert mir jetzt nicht mehr. Peter
>Ich bin also gar kein richtiger Programmierer.
Der war gut! Wenn DU kein richtiger Programmierer bist, wer dann?
Hut ziehend
Katapulski
Ach so: Zurück zu der Frage, ob BASCOM nicht nur von Bastlern verwendet wird. Ich habe hier 3 Leute, die ein Ingenieurbüro führen. Sie schreiben eine ganze Menge ihrer Sachen damit. Dabei geht es vor Allem um einfache Ablaufsteuerungen für Maschinen, von denen oft nur ein Exemplar gebaut wird. Dort sind die Abläufe nicht so zeitkritisch und es kommt nicht darauf an, das letzte Byte im Flash nicht zu belegen. ;-) Ich selbst bin auch ein Fan davon, wobei ich in letzter Zeit auch an AVR-Assembler nicht vorbeigekommen bin, denn die Library-Dateien in Bascom sind ja auch in Assembler geschrieben. Wenn man daran etwas zu ändern hat, muß man ja verstehen, was dort vorgeht. gez. Katapulski
na is das nich generell so? kleine sachen bzw projekte die nicht wirklich zeitkritisch sind werden in bascom geschrieben..aber sobald es auf genaue zeiten ankommt nimmt man c oder besser assembler? wobei ich mir assembler recht schwer vorstellen wenns um sehr große projekte geht?
also ich habe bisher genau 0 mal in basic programmiert und bin ehrlich gesagt stolz drauf. gut ich bin nicht normal und nicht der nabel der welt, aber basic habe und werde ich nie einsetzen. ps: ja. asm und richtig grosse projekte sind nicht wirklich lustig, aber geschickt passagen per inline asm rein gefrickelt oder spezielle funktionen... das ist durchaus akzeptabel bis sinnvoll. senf
Obwohl ich auch Bascom verwende (nicht ausschließlich) bezweifle ich ernsthaft das 70% der AVR Anwender Bascom benutzen. Ich denke das C verbreiteter ist. (Ich mag C nicht und bin froh das ich es nciht mehr machen muß. Dann schon lieber Assembler!) Die meisten wissen nicht mal was wirklich wichtig am Programmieren ist. Es ist das "wie" und nicht die Programmiersprache. Wer meint Programmieren zu können weil er eine bestimmte Programmiersprache benutzt, der tut mir leid. In den einschlägigen Foren findet man viele Hilferufe quer durch alle Programmiersprachen. Das rumbetteln nach fertigen Libs und Routinen ist nicht nur bei Bascom zu sehen. Assembler zu programmieren hat zumindest den Vorteil das die meisten dann wenigstens genau wissen was intern im Controller abgeht. Bei so einem Wettbewerb eine Sprache vor zu schreiben ist natürlich eine ziemlich dumme Einschränkung. Aber ich bin sicher das man nur ein wenig googlen muß um ähnliches mit z.B. C zu finden. Ich denke in diesem Wettbewerb steht Finanzielles Interesse dahinter. Aber bei welchem Wettbewerb ist es das nicht?
> also ich habe bisher genau 0 mal in basic programmiert und bin ehrlich
gesagt stolz drauf. gut
Bist du noch keine 14? So ein Schwachsinn kenne ich eigentlich nur von
jungen Schülern die meist weder C, Assember noch Basic auch nur
annährend beherrschen. Sie meinen wenn Sie in C etwas kleines
zusammenfriemeln wären Sie Könner. Die haben nicht verstanden um was es
geht und werden es vermutlich auch nie. Beim Programmieren geht es um
Aufgaben, Ziele, Problemstellungen die in möglichst kurzer Zeit mit
möglichst geringen Aufwand durch geeignete Algorithmen perfekt gelöst
werden müssen. In den meisten Fällen ist man mit Bascom hier viel
produktiver und das zu erkennen, das zeichnet den Profi-Programmierer
aus. Sicher gibt es auch Aufgaben wo C und Assembler angesagt ist, auch
das muss dann ein Profi erkennen, aber das ist relativ selten der Fall.
Peter Dannegger wrote: > Ich kann Dir sagen, das sämtliche Programmierer bei mir in der Firma zu > exakt 0% in Bascom/Basic programmieren. Kein ernst zu nehmender Entwickler schreibt in BASIC. Aber das ist ja wohl kein Geheminis.
Michael G. wrote: > Kein ernst zu nehmender Entwickler schreibt in BASIC. Aber das ist ja > wohl kein Geheminis. Ich hab nie verstanden wieso. Ich bin seit Jahren VB-Entwickler. Ich schreibe ebenso funktionale wie ansprechende Anwendungen in VB wie meine Kollegen in Visual C oder C#. Ich hatte bisher kein Problem, welches ich in VB nicht gelöst bekam. Zugegeben ich bin mit Basic groß geworden. TI-99/4A, C64, C128D, PC mit QuickBasic, Visual Basic, Gambas und auf dem µC Bascom, ... das zieht sich wie ein roter Faden durch mein Leben. Ich behaupte, dass es darauf ankommt, dass ein Entwickler sein Werkzeug beherrscht. Mag sein, dass man vielleicht mit Basic nicht so Laufzeit- und Speicheroptimiert entwickeln kann, wie vielleicht in C oder noch hardwarenaher in Assembler, oder das VB nicht so hip ist wie C oder Java, aber das hat mich noch nie gestört. Ich nutz ja auch unter Linux immernoch das gute alte Perl, obwohl es nicht so hip ist wie Ruby on Rails. ;) Gruß Dominique Görsch PS: Ach ja, ich nutz VB nicht nur aus Spaß, sondern hab damit schon einige Kunden glücklich gemacht. :)
hmmm ruby... neumodisches zeuch... perl oder sed/awk und gut is. ack.
Hallo und guten Morgen, mir fallen die Worte meines Profs in einer Vorlesung in der es um Pascal ging ein als er nach Syntax gefragt wurde: "Ich bin doch kein wandelndes Pascal-Lexikon, wenn Sie soetwas wollen dann gehen Sie in die Bibliothek, einem echten Entwickler kommt es doch nicht auf Syntax an, dem ist es egal ob er sein Programm in Pascal, Basic, C, C++, Assembler oder gar JAVA schreibt." Und heute weiss ich: Recht hat er! Es kommt drauf an, dass man versteht, was man machen möchte. Eine Programmiersprache ich der Weg zum Ziel, nicht mehr und nicht weniger. Die eine Sprache ist eben für Wege des Typs A besser geeignet, die andere Sprache für Wege des Typs B und/oder für Entwickler A und/oder Entwickler B. Dieses ganze "ich hasse Basic" oder "C ist das einzig Wahre" ist totaler Bockmist und kommt von Leuten, denen die Sprache wichtiger ist als ein gutes Ergebnis und von Toleranz haben die auch noch nichts gehört. Nur mal so zum Nachdenken. Grüsse und einen guten Start in die neue Woche Michael
Michael S. wrote: > Es kommt drauf an, dass man versteht, was man machen möchte. Eine > Programmiersprache ich der Weg zum Ziel, nicht mehr und nicht weniger. Wenn das Ziel lautet: Möglichst portablen Code zu erzeugen, dann ist BASCOM aber nunmal der falsche weg. Denn es ist und bleibt ein proritärer Compiler. Für kleine Quick&Drity Projekte vielleicht ok, ab wenn das Projekt in 5 Jahren vielleicht mal neu auf einem größeren µC laufen soll, dann ist BASCOM eindeutig die falsch Wahl. Und wenn es irgendwann MSC nicht mehr gibt gibt, kann man alles nochmal neu programmieren.
@gast: proprietär, das meinst ;) Die größte Schwäche von Basic ist die Nichteinhaltung von Normen. Jeder Compiler kocht sein eigenes Süppchen - aber in den Grundzügen passt es dann doch wieder. Ich selbst programmiere (inzwischen) sehr gern mit C, früher war ASM mein Favorit - aber Basic hat auch seinen Reiz. Basic haften von früher viele Vorurteile an, es sei langsam, ineffektiv. Wenn man sich den C64-Interpreter mal genauer anschaut, sieht man auch, dass der damalige Programmierer alles getan hat, es langsam zu machen (da wundert dann nicht mehr, dass dieses Basic von Microsoft kam). Inzwischen ist Basic schon lange erwachsen geworden und kann es problemlos mit anderen Sprachen aufnehmen. Schlußendlich ist es eine Frage der Umsetzung. Während man bei C ständig im Datenblatt schauen muss, welches Bit in welchem Register gesetzt werden muss, ist es bei Basic eben die Befehls-Referenz ;) Schlussendlich muss man zugeben, dass Bascom für µC-Anfänger ein wesentlich einfacherer Einstieg als C ist. Ich habe schon min. 5 Anfängern Bascom empfohlen, und alle sind sehr zufrieden, weil unglaublich schnell Ergebnisse erzielt werden. Ich selbst bin noch ein Wackelkandidat, mir ist Bascom noch etwas zuviel "Black-Box", man bekommt schon zuviel Arbeit abgenommen - aber ich wanke bereits ;)
Halle Leute, wenn man hier liest wird man das Gefühl nicht los dass sich in diesem Forum eine Unmenge ignorranter Dummköpfe bewegen. Ich schreibe seit fast 30 Jahre Software und hatte nie ein Problem mit einer Programmiersprache. Meine ersten Programme wurden noch auf einem Blatt Papier codiert und dann mit einer 16er Tastatur in den Controller gehackt (war übrigens bereits ein 8048). Lange Zeit gab es für mich nichts anderes als Assembler. Als erste Hochsprache habe ich Basic gelernt, war ein Horror aber nicht wegen der Sprache. Mit der Hochsprache wusste ich plötzlich nicht mehr was die Hardware wann tatsächlich tut. Ich habe Industriesteuerungen mit Basic programmiert, da dieses Basis damals die einzige Programmiersprache war welche in ihrer Syntax Befehle zur Unterstützung von Multitasking enthielt. Ich habe aber auch Programmiersprachen benutzt, welche viele von Euch nicht mal kennen (kleiner Auszug Fortran, Ada, Forth, Smalltalk, ...). Wichtig bei einer Problemlösung ist aber das WIE und nicht das WOMIT. Daher lasst diejenigen, welche gerne Software in Basic schreiben, diese in Basic schreiben, diejenigen die C lieben werden ihre Programme in C schreiben, andere verwenden Assembler, Pascal oder Java. Wenn das Ergebnis dem Ziel angemessen ist ist das doch OK. Wenn ein Wettbewerb eine Programmiersprache vorschreibt wird das seine Gründe haben, seien diese kommerziell oder auch anderer Natur. Ich kenne das Roboter-Forum und weiss, dass dort ein Grossteil der Leute in Bascom programmiert, vielleicht ist auch das der Grund. Und wer an diesem Wettbewerb nicht teilnehmen möchte, kann es ja bleiben lassen. Wer aber gierig auf den Gewinn von € 500,- ist, der soll die Bedingungen akzeptieren und nicht maulen. Gruss an alle und weiter viel Spass ein Alter Hase
marvin m. wrote: > Schlussendlich muss man zugeben, dass Bascom für µC-Anfänger ein > wesentlich einfacherer Einstieg als C ist. Ich habe schon min. 5 > Anfängern Bascom empfohlen, und alle sind sehr zufrieden, weil > unglaublich schnell Ergebnisse erzielt werden. Da stimme ich dir uneingeschränkt zu. Es ist einfach, aber es nimmt einem das selbständige Denken zumindest teilweise ab, und das ist gefährlich: > Schlußendlich ist es eine Frage der Umsetzung. Während man bei C ständig > im Datenblatt schauen muss, welches Bit in welchem Register gesetzt > werden muss, ist es bei Basic eben die Befehls-Referenz ;) Es gab hier im Forum schon Leute, die Software in BASCOM in der Codesammlung für ein Oszilloskop mit einem AVR gepostet haben, im Code übelst rumgepfuscht haben, um eine hohe Datenrate AVR->PC zu erzielen, aber nichtmal wussten dass es einen ADC Prescaler gibt, mit dem man die ADC Taktrate und somit die Samplerate einstellen kann (der daher mit einem langsamen Takt lief, weshalb die Messungen einfach nur Mist waren). Sowas kann ich C nicht passieren, denn denn wenn man die Register nicht selbst setzt, setzt sie keiner, und das merkt man schnell. Und wenn man hier im Forum liest, merkt man schnell, dass es vor allem Leute sind die in BASCOM programmieren, die bei kleinsten Problemen die es so nicht vorgefertigt gibt, aufgeben, da sie mit dem Datenblatt überfordert sind (bzw. nichtmal wissen dass es hilfreich wäre das mal zu lesen). Das ist der Grund wieso zumindest ich kein BASCOM mag: Man kann zwar programmieren, aber hat letzendlich Null Ahnung von einem µC, wenn man aktiv nichts dagegen unternimmt. In C wird man quasi zur Selbständigkeit gezwungen.
>Das ist der Grund wieso zumindest ich kein BASCOM mag: Man kann zwar >programmieren, aber hat letzendlich Null Ahnung von einem µC, wenn man >aktiv nichts dagegen unternimmt. In C wird man quasi zur Selbständigkeit >gezwungen. Das stimmt so nicht. Die Lernkurve ist nur anders. In Bascom steigt man tatsächlich ohne tiefere Microprozessorkentnisse ein und kommt auch schnell zum Ziel, dem fertigen Programm. Erst nachdem an einige Programme geschrieben und höhere Anforderungen an da sProgramm hat lernt man STück für Stück die internen Eigenschaften des Controllers kennen. Da hilft übrigens auch die gute Bascom Dokumentation kräftig beim lernen. C und erst Recht Assembler programmierer quelen sich von Anfang an duch das Microcontroller Interna. Sie sind froh wenn Sie nach Stundne von Arbeit endlich ein paar Buchstaben zum PC sendne können - also Aufgaben die Bascom in einer Zeile erledigt. Das führt dazu das C und Assembler Einsteiger nicht selten nach Tagen oder Wochen die Lust verlieren und den Mikrocontroller nie mehr anfassen. Also mir ist der bequeme Weg lieber, zumal er keinen Nachteil bietet. Und wie man stolz sein kann eine Programmiersprache "nicht zu können" ist mir auch schleierhaft. Man muss nicht alle können, aber darauf muss man trotzdem nicht stolz sein.
Also ich käme mir schon ziemlich hilflos vor, wenn ich ohne Arrays, Strukturen, Funktionspointer usw. auskommen müßte. Und pro Rechenoperation immer ne extra Zeile, läßt den Quellcode doch schnell lang und unübersichtlich werden. Ich halte C für viel mächtiger und universeller. Vielleicht kann mir ja mal ein Bascom-Experte zeigen, wie dieses einfache Scheduler Beispiel in Bascom aussehen würde: Beitrag "Wartezeiten effektiv (Scheduler)" Und Filesysteme, TCP/IP usw. habe ich bisher nur in C geschrieben gesehen. Oder kennt jemand sowas auch als Bascom-Source? Peter
Zum einen gibt es Array´s und zum anderen kann man auch direkt auf Speicherstellen zugreifen, was in etwa einem Pointer entspricht. Das nur einzelne Rechenoperationen pro Zeile möglich sind ist in der Tat ein kleines verbesserungswürdiges Manko von Bascom, allerdings solltest du sowas erstmal in Assembler machen - dort brauchst du zahlreiche Zeilen für solch kleine Operationen. Da gibts übrigens auch keine Strukturen. Natürlich gibts für Bascom auch Lib´s für TCP und Filesysteme, alles kein Problem. In jedem Fall ist ein Bascom Programm im Source wesentlich kürzer als ein C Programm und zudem wesentlich besser lesbar. gerade deshalb ist es ja so beliebt.
Der [?]-Code ist nicht portabel... wenn ich das nur schon hoere... Ist er eh nicht. Weder in C noch in sonstwas. Ausser vielleicht auf den naechst groesseren AVR. Portabilitaet bedeutet die Idee ist portabel, nicht der Code. Und um die Idee bestmoeglich portieren zu koennen muss die Spache uebersichtlich und intuitiv sein. Leider gehoert u+=(1<<1) nicht dazu.
Wettbewerbe dienen dazu guenstig zu neuen Ideen und Talenten zu kommen.
Bastler wrote: > zum anderen kann man auch direkt auf > Speicherstellen zugreifen, was in etwa einem Pointer entspricht. Davon habe ich nicht geredet, sondern von Funktionspointern. Funktionspointer (Callbacks) werden in größeren Programmen sehr häufig benötigt. Abgesehen davon, ist ein Speicherzugriff keinesfalls einem Pointer auch nur ähnlich. Wenn ich in C einen Pointer auf ein Strukturelement zeigen lasse, muß ich nicht wissen, wie er diese Struktur intern abgelegt hat. Ich kann mich einfach voll darauf verlassen, daß der Compiler die richtige Anzahl Bytes in der richtigen Reihenfolge mit dem richtigen Offset zu der richtigen Basisadresse liest. > Natürlich gibts für Bascom auch Lib´s für TCP und Filesysteme Davon habe ich nicht geredet, sondern wie man Bibliotheken erstellt. Bibliotheken sind nichts statisches, man muß sie geänderten Erfordernissen anpassen können oder Fehler beheben (Bibliotheken werden ja nicht von Gott erschaffen). Wenn für Bascom deartige Bibliotheken erstellt wurden, dann mit Sicherheit in C. Entweder es wurde für Bascom ein C-Interface (Calling-Konventionen, Stack, Register) erstellt oder jemand hat sich die Mühe gemacht, den Assembleroutput des C-Compilers mit Bascom zu verwursten. > In jedem Fall ist ein Bascom Programm im Source wesentlich kürzer als > ein C Programm und zudem wesentlich besser lesbar. Aber nur, wenn Du die verwendeten Bibliotheken (Blackboxes) nicht mitzählst. Allerdings ist die Philosophie bei C ne andere. Bibliotheken werden erstmal lange Zeit als Quelltext (z.B. im Example-Verzeichnis) belassen und nur wenn sie sich bewährt haben und fehlerfrei scheinen, wird ne Objekt-Bibliothek gemacht. Daher scheint es, daß für C weniger Bibliotheken bestehen, was aber nicht der Fall ist. Peter
... Ich bin also gar kein richtiger Programmierer. ... Das stimmt.
05 FOR I=1 to 1000 10 PRINT "BASCOM kenne ich nicht... "; 15 NEXT i
Ohh wrote: > Der [?]-Code ist nicht portabel... wenn ich das nur schon hoere... Ist > er eh nicht. Weder in C noch in sonstwas. Gut geschriebener C-Code ist sogar sehr gut portabel. Schau dir mal FreeRTOS an, elm chans FATFS-Bibliothek oder Peter Danneggers Entprellungsroutinen. Die sind wunderbar portabel und wurden schon auf einem halben Dutzend verschiedener Architekturen getestet. Ich bin kein Freund der Sprache Basic, finde aber dass BASCOM durchaus eine Daseinsberechtigung hat. Wenn es um einfache Steuerungsaufgaben geht und es nicht auf Portabilitaet oder das letzte Prozent Effizienz ankommt (Einzelstuecke, Prototpen), dann ist BASCOM gut geeignet.
5 FOR I=1 to 1000 10 PRINT "BASCOM kenne ich nicht... "; 15 NEXT i 20 GOTO 5 RUN
Peter Dannegger wrote: > Wenn für Bascom deartige Bibliotheken erstellt wurden, dann mit > Sicherheit in C. Es gibt auch einen TCP/IP-Stack komplett in Bascom. Sogar fein säuberlich erklärt wie alles Funktioniert und leicht anzupassen. Inkl. kleinem Webserver und "Treiber" für einen RTL8019AS: http://members.home.nl/bzijlstra/software/examples/RTL8019as.htm Gruß Dominique Görsch
>Davon habe ich nicht geredet, sondern von Funktionspointern. >Funktionspointer (Callbacks) werden in größeren Programmen sehr häufig >benötigt. Bascom ist sehr maschinennah! Natürlich kannst du auch Adressen direkt anspringen und manipulieren was dann einem Funktionspointer entspricht. Du kannst auch mitten im Code Assembler Code einfügen. Aber gewöhnlich ist der Pointer Kram in Bascom garnicht notwendig, was die größte Fehlerquelle der C-Programmierer vermeidet
Bastler wrote:
> Bascom ist sehr maschinennah!
Ja ne, is klar.
Maschinennah heißt nicht, dass Inline Assembler möglich ist. Also Print
"Hallo" finde ich nicht gerade sehr maschinennah.
Wenn jemand mal versucht hat, mit einem 12F675/etc Video-Signale zu erzeugen, weiss genau, dass es hier auf den letzten CPU-Cycle ankommt, damit das Timing stimmt. Da geht kein BASIC! Auch bei einem Software-UART geht kein BASIC (es sei denn, dieses hat effiziente ASM-Librarys eingebaut). Ausschnitt einer Video-Generator Routine
1 | ...... |
2 | RLF GPIO,F ;ROTATE BIT 6 OUT OF CARRY |
3 | RLF INDF,W ;ROTATE BIT 7 INTO CARRY |
4 | RLF GPIO,F ;ROTATE BIT 7 OUT OF CARRY |
5 | BCF GPIO,0 |
6 | BTFSC LINECTR,2 ;CHECK IF ON 5TH LINE |
7 | BSF GPIO,0 ;MAKE A SEPARATOR DOT |
8 | NOP ;MAKE DOT SAME SIZE |
9 | BCF GPIO,0 ;REMOTE THE DOT, IF ANY ;;22 INSTRUCTIONS... 4.4 US |
10 | BTFSC FSR,1 ;SKIP IF DATE OUTPUTED |
11 | GOTO PUTTIME |
12 | INCF FSR ;NEXT VRAM LOCATION |
13 | ..... |
Wenn man solche Realtime Anwendungen macht, dann muss man ASM programmieren. Mit Realtime meine ich Mikrosekunden! Der Vorteil ist jener, dass der Programmierer selbst optimieren kann. Man muss einen Kompromiss zwischen Geschwindigkeit (CPU-Cycle) und Speicherbelegung (RAM, ROM) machen. Vor allem, da man in einem 12F675 keinen Hardware-Shifer (SPI) oder andere HIlfsmittel hat. Ausserdem muss man mit dem RAM (64 Bytes) und dem ROM/Flash (1K Words) auskommen. Wenn man nur Taster abfragt, ist das egal, oder wenn man Aufgaben, die mit 5 MIPS zu schaffen sind auf einem ARM7TDMI macht. Man sollte den MCU nicht als "Blackbox" betrachten!
>Wenn jemand mal versucht hat, mit einem 12F675/etc Video-Signale zu >erzeugen, weiss genau, dass es hier auf den letzten CPU-Cycle ankommt, >damit das Timing stimmt. Sicherlich sind solche Spezialanwendungen nur mit etwas Assemblercode machbar, das will keiner bestreiten. Aber es spricht ja nix dagegen das man solchen Code in ein Bascom Programm einbettet. Es gibt übrigens sowas schon für Bascom!
Sprache hin -- Sprache her. Im Endeffekt sind sie gleich mächtig. In der Sinne, daß beide ebenso mächtig sind wie Turing-Maschinen ;-) Soviel zur Theorie. In der Praxis will man die Resourcen der Hardware möglichst gut nutzen, also nicht unnötig Platz und Zeit vertrödeln. Wie ein Programm umhgesetzt wird, ist nur soweit an die Sprache gebunden, wie diese spezifiziert ist. Darüber hinaus bleibt viel Raum, dichten und/oder schnellen Code zu finden. Er muss nur genutzt werden. Wenn man BASCOM mit avr-gcc vergleicht und schaut, was beide aus
1 | i := i-1 |
machen, dann braucht gcc idR dazu 2 Takte und maximal 4 Bytes Code, während BASOM einen Call(!) macht
1 | LD ZL,X+ |
2 | LD ZH,X |
3 | SBIW ZL,0x0001 |
4 | ST X,ZH |
5 | ST -X,ZL |
6 | RET |
weil es Werte nie in Registern hält, sondern nur auf einem eigenen Soft-Stack operiert. Allein die Laufzeit des BASCOM-Codes wäre ein absolutes Killerkriterium in vielen meiner Applikationen. Beispiel 1 6 Nixie-Röhren (jede braucht 4 Ports) hängen nebst Lautsprecher etc an einem SPI-Bus mit 4 Expandern 74*595. Per 20kHz bzw alle 800 Ticks müssen 4 Bytes gesandt werden. Das Senden ist kein Problem, das macht die Hardware. Aber über den SPI läuft für jede Kathode ne Soft-PWM zum Dimmen/Überblenden, und die Daten müssen für jeden Frame neu berechnet werden. Selbst eine Verspätung von einem Främe lässt die Röhren zappeln. Beispiel 2 Eine Uhr hat zur Anzeige eine 3*(9 LED + 1 Taster) Matrix. Die LEDs werden per Soft-PWM angesteuert. In einer PWM-Lücke wird eine LED-Zeile als Photodioden geschaltet und die Umgebungshelligkeit gemessen, um den LEX-Helligkeit an die Umgebungshelligkeit anzupassen. Beispiel 3 Pixel auf ne Oszi-Röhre pinseln. Die erreichbaren Pixel/Sekunde kann man sich aufteilen in Pixel/Frames * Frames/Sekunde, also Bildauflösung * Zeitauflösung. Je mehr, desto besser. avr-gcc schafft bei einem ATmega88@24MHz 32000 Pixel/Sekunde. Wieder ist das Ding nicht, die Pixel zu setzen, sondern in Echtzeit zu berechnen (Vektorfonts, Linien, Kreise, Fraktale, Morphing). Ergo Vom Peis-Leistungs-Verhältnis sehe ich keinen Grund für BASCOM, zumindest was den erzeugten Code angeht. Es scheint so programmiert, wie ein unbescholtener Ingenieur sich einen Compiler vorstellt: Jedes Hochsprach-Element wird in eine bestimmte, vordefinierte Assembler-Sequenz abgebildet. Fertig. Kann man breiten Code durch nen immer fetteren AVR kompensieren, ist man bei der Geschwindigkeit fix am Deckel. Und warum soll ich nen ARM/i386/TriCore/PPC nehmen, wo ein AVR reicht? C-Code kann ich so schreiben, daß er ebenso auf dem PC wie auf nem AVR-Winzling läuft. Komplexere Software fang ich auf dem PC an und hab dort die volle Power von Grafik uns Analysetools, was ich in nem Simulator nicht hätte. Was an BASCOM nett zu sein scheint sind die ganzen Bibliotheken und daß es vielen den Einstieg in die µC-Welt einfach macht und nicht gleich abschreckt. Allerdings gibt's auch genug Teenager, die ihren Asuro in C proggen. Was mir schleierhaft ist, ist daß BASCOM noch nichtmal schafft, komplexere Ausdrücke zu verarbeiten. Sowas bringt ein simpler, frei verfügbarar Parser wie bison frei Haus, und der erzeugte Code muss dennoch nicht unter die GPL. Mir scheint, da hat wer seine Hausaufgaben nicht gemacht...
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.