Wenn ich mir als Assembler und C Fan die Bemerkung erlauben darf, ist
Bascom schlichtweg ein Hammer. Musste schnell einen XMega für ein GSM
Gateway proggen.
Notwendig waren 3 UARTs,SPI,1Wire und I2C. Das Brutale war dann noch das
Management einer SD Card.
In C mit Studio 6 eine wissenschaftliche Arbeit und eigentlich unmöglich
unter 40 Stunden. Mit Bascom war das ohne Kenntnis der Umgebung in 2
Tagen erledigt. Respekt vor den Entwicklern. Was denkt ihr über Bascom?
Schöne Grüße Duplo
duplo schrieb:> Was denkt ihr über Bascom?
Finde es super.
duplo schrieb:> Respekt vor den Entwicklern.
Meinen haben sie. Dabei sind es wohl gar nicht mal so viele.
Wenn Atmel endlich mal gute Software machen würde (Studio 4 geht
halbwegs) wäre das Programmierer Leben um vieles einfacher. Eh logisch.
Da bin ich über Bascom schon froh, wenn's mal schnell gehen muss.
Wenn ich auf einem (Höllen)Trip bin, dann ist Studio 6 mit einem XMega
schon
geil (wenn man sich gerne selbst foltert). Hat aber seinen Reiz ;-)
Schöne Grüße Chulio
Wir sind doch alle mit Basic groß geworden. Seit doch nicht so
undankbar!
Denkt grad an den C64 und das AH8052 Basic. Basic war und ist sehr gut
und die Mutter aller Programmiersprachen. Das an alle abgehobenen C
Progger.
Gruß Lueger
Im µC-Umfeld sollte Bascom, für einen ökonomisch denkenden Generalisten,
den gleichen Stellenwert haben wie C. Bei der Nachkalkulation fragt kein
Mensch mehr, auf welcher linguistischen Basis das Produkt enstanden ist,
sondern nur noch was es gekostet hat.
Hans Peter
Hans Peter B. schrieb:> Im µC-Umfeld sollte Bascom, für einen ökonomisch denkenden Generalisten,> den gleichen Stellenwert haben wie C. Bei der Nachkalkulation fragt kein> Mensch mehr, auf welcher linguistischen Basis das Produkt enstanden ist,> sondern nur noch was es gekostet hat.
Dennoch stellen dieselbigen Verantwortlichen Niemanden ein, der an der
Stelle von guten altem C nur Bascom spricht.
Gruß Oliver
Ich habe nun auch meinen inneren Schweinehund überwunden und mich in C
eingearbeitet. War anfangs nicht ganz leicht, aber inzwischen habe ich
mich damit angefreundet. Allerdings fehlt mir in C der Basic-typische
Goto Befehl und der damit einhergehende Spaghetti-Code. Aber man kann
halt nicht alles haben.
Oliver J. schrieb:> Hans Peter B. schrieb:>> Im µC-Umfeld sollte Bascom, für einen ökonomisch denkenden Generalisten,>> den gleichen Stellenwert haben wie C. Bei der Nachkalkulation fragt kein>> Mensch mehr, auf welcher linguistischen Basis das Produkt enstanden ist,>> sondern nur noch was es gekostet hat.>> Dennoch stellen dieselbigen Verantwortlichen Niemanden ein, der an der> Stelle von guten altem C nur Bascom spricht.
Und das machen die auch nicht aus Witz. Jeder der schonmal ein Produkt
entwickelt hat (kein Hobbyzeugs) der weiß wovon ich spreche. Kannst ja
mal in einen Betrieb gehen und sagen du willst ein Prjojekt mit Bascom
realisieren - da wird man dich auslachen. C ist eine derart triviale und
einfach zu erlernenden Sprache - das sind einfach Mindestanforderungen.
Wer sowas nicht mitbringt, der hat auch im beruflichen Sektor nichts zu
suchen. Für den Hobbybereich mag das durchaus legitim sein.
duplo schrieb:> Wenn ich mir als Assembler und C Fan die Bemerkung erlauben darf, ist> Bascom schlichtweg ein Hammer. Musste schnell einen XMega für ein GSM> Gateway proggen.> Notwendig waren 3 UARTs,SPI,1Wire und I2C. Das Brutale war dann noch das> Management einer SD Card.>> In C mit Studio 6 eine wissenschaftliche Arbeit und eigentlich unmöglich> unter 40 Stunden. Mit Bascom war das ohne Kenntnis der Umgebung in 2> Tagen erledigt.
Das ist die Frage - was genau ist denn an Bascom so unbedingt
schwieriger als an C. Gut C ist etwas kryptischer (für Anfänger) und
maschinennäher. Gerade bei bei der Fehlersuche ist das so hilfreich.
Dazu bedarf es aber viel Übung. Aber dann ist C unschlagbar, spitze
durchstrukturiert, keine riesige Codehäufen wie bei Bascom ... Ich finde
das auch optisch schöner.
Nicht, dass wir uns falsch verstehen, ich respektiere jeden, der Bascom
programmiert. Das muss jeder für sich selbst entscheiden. Ich finde es
auch gut, dass z.B. mit Arduino auch dem "nicht-Programmierer" eine
Möglichkeit geschaffen wird in die Welt der Hobbymikrocontroller
einzusteigen. Dennoch muss man sich immer seines Wissenstandes bewusst
sein und wissen, wo man auf der Skala der Mikrocontrollerprogrammierung
steht.
Bascom mag für lernrestistente Hobby Frickler ja durchgehen, Aber im
industriellen Umfeld ist diese proprietäre "Programmiersprache" ein
absolutes nogo. Klingt zwar hart ist aber so. Ergo: "C" lernen und
verinnerlichen, dann klappts auch mit dem angestrebten Entwickler-Job.
Weg mit diesem Basic Gefrickel schrieb:> dann klappts auch mit dem angestrebten Entwickler-Job
Wo stand da im Eingangspost etwas von einem angestrebten Entwickler-Job?
Es geht doch nur darum, ob andere Bascom auch für schnelle Projekte
nutzen würden.
Ich selbst nutze zwar Assembler und C, da mir Bascom mit der Basic
Syntax nicht gefällt, aber deshalb darf man das nicht alles gleich
schlecht heisen.
Für manchen Bastler ist der schnelle Erfolg wichtiger, als das 100%
korrekte. Mein Ziel ist zwar auch immer das 100%, aber hin und wieder
mache ich da auch abstriche, da ich zum einen das Wissen nicht habe und
zum anderen auch mal den schnellen erfolg wünsche.
Daher sage ich mal so, wenn ich mich mit der Basic Syntax anfreunden
könnte und ich einen sehr schnellen erfolg haben wollte, dann würde ich
es auch nutzen. Anstreben möchte ich aber, das ich Assembler und C
behersche.
Assembler, da es hardware näher ist und viel mehr Wissen benötigt (habe
ich selbst schon festgestellt, das man Assembler nicht mal eben in 2
Wochen lernt) und C um damit schnelle erfolge zu erziehlen.
Ex Basic Frickler (Gast) schrieb:
> Ich habe .. mich in C> eingearbeitet. .. War nicht leicht ..> Allerdings fehlt mir in C der Basic-typische> Goto Befehl und der damit einhergehende Spaghetti-Code. Aber man kann> halt nicht alles haben.
Wieso fehlt goto? Ist doch noch da
http://de.wikibooks.org/wiki/C-Programmierung:_Schl%C3%BCsselw%C3%B6rter
Stellt sich die Frage, warum es in C nach mehr als 4 Jahrzehnten noch
immer ein goto gibt, während viele Basic Dialekte heutzutage längst
genügend strukturierende (Schleifen-) Befehle mitbringen, die das alte
goto überflüssig machen?
Überraschter schrieb:>> Stellt sich die Frage, warum es in C nach mehr als 4 Jahrzehnten noch> immer ein goto gibt, während viele Basic Dialekte heutzutage längst> genügend strukturierende (Schleifen-) Befehle mitbringen, die das alte> goto überflüssig machen?
Programmiere einen Treiber und du wirst es verstehen.
Tim T. (tim_taylor) schrieb:
> Programmiere einen Treiber und du wirst es verstehen.
Du meinst der goto Befehl ist elementar bei der Treiberprogrammierung?
Dann ist BASIC die Sprache schlechthin um Treiber zu programmieren.
:-)
Das Wort Generalist
(Wiktionary: Lebewesen mit vielfältigen Möglichkeiten, das unter
vielerlei Bedingungen zurechtkommt)
bezog sich nicht auf den alles entscheidenden "Firmen-Obristen", sonden
auf den Entwickler, welcher nicht nur auf der C-Schiene fährt, sondern
auch für kleinere Projekte Bascom kostengünstig anzuwenden weiss.
Hans Peter
Ich programmiere PICs in PicBasic Pro
BASIC wird überall sofort verteufelt. Ist halt so !
Ich kann in PicBASIC sehr schnell Erfolge liefern. Ich nutze die
Sprache, um meine Befehle abzuarbeiten und nur etwas Struktur (IF,
Sprünge, etc.) einzubringen.
Ich stelle mir jeden Befehl in Assembler vor und vermeide unnötigen
Ballast.
Gerade im Hobby-Umfeld sehe ich oft C-Programme, die einfach mal so eben
Floating-Point nutzen um eine Zahl in einen String umzuwandeln und sich
dann wundern, warum das Programm nicht in den Micro-uC paßt.
Das passiert mir bei PicBASIC nicht, weil es das nicht gibt. Basta.
Ich habe zur Zeit ein Projekt, das 6000 Zeilen Code umfaßt, das ich
bestens beherrsche. Bei Programmen in C komme ich da eher durcheinader.
Ein einziges falsches Zeichen bringt keine Fehlermeldung, sondern
anderen Code.
Die Syntax von C aus einer kruden Vermengung einzelner Ziffern und
Zeichen stellt gerade den Anfänger auf eine harte Probe.
Und wer glaub, C sei portabel... Gerade bei uCs hat jeder Hersteller
seine eigenen Libs für die Ansteuerung der Hardware. Da kann man
jedesmal alles anpassen.
Bei PicBasic (also BASIC) verzichte ich auch diesen Librarys-Wahnsinn
und programmiere die Zugriffe auf die Hardware selbst in der Art, daß
der erzeugte Code schon optimiert für den Assembler ist. Der Compiler
hilft mir bei dem Mapping der Variablen (das ist echt eklig) und für
Interrupts schreibe ich Assemblercode rein.
Wenn ich in C anfange, dann hört es für mich eigentlich schon beim
"viod" auf und bei der Auftrennung in Header- und Source-Files. Das mag
für den Theoretiker mit der Nickelbrille ganz toll sein, aber wir wollen
nicht den Mondflug programmieren mit Abteilungs-übergreifenden Librarys,
sondern es gibt eine Lösung. basta !
Am Ende gibt es ein .hex-File zum Brennen (inkl. der Fuse-Bits !!!!!).
Oder einen Menschen mit Verstand, der den Klartext eines BASIC-Programms
lesen kann und mit den Kommentare den Sinn schnell versteht.
und jetzt könnt ihr mich verbrennen ;-)
Bernd Rüter schrieb:> Gerade bei uCs hat jeder Hersteller seine eigenen Libs für> die Ansteuerung der Hardware. Da kann man jedesmal alles anpassen.
Richtig.
Man KANN es anpassen, man KANN es portieren.
Man KANN ein zukunftsfähiges, wartbares Produkt erzeugen.
In diese Versuchung kommst Du mit BasCom erst gar nicht, das ist ein
Grund, warum Du deswegen regelmäßig ausgelacht wirst.
> Wenn ich in C anfange, dann hört es für mich eigentlich schon beim> "viod" auf und bei der Auftrennung in Header- und Source-Files.
Das ist dann allerdings Dein Problem, und nicht das von C. Das ist noch
ein Grund :-)
Im industriellen Umfeld ist Bascom ein nogo. Liegt nicht nur an der
Sprache an sich sondern auch an deren Lizensierungsbedingungen. Also für
lernresistente Hobbyisten durchaus möglich, für professionelle
Anwendungen allerdings keine echte Alternative. Oder kennt jemand eine
kommerzielle Anwendung die Bascom verwendet? Ich nicht!
Lueger schrieb:> Basic war und ist sehr gut und die Mutter aller Programmiersprachen.
Nein, das ist Lisp :)
Tim T. schrieb:> Nur mal zur Ansicht:
1
if(register_chardev(...)notfailed){
2
if(request_region(...)failed)
3
gotoout_region;
4
if(request_irq(...)failed)
5
gotoout_irq;
6
return0;// success
7
}
8
else{
9
gotoout;
10
}
11
12
out_irq:
13
free_region(...);
14
out_region:
15
unregister_chardev(...);
16
out:
17
return-EIO;
Autsch! Das ist ja ein geradezu perfektes Paradebeispiel dafür, wie man
Gotos nicht benutzen sollte. Warum schreibst du nicht einfach
1
if(register_chardev(...)notfailed){
2
if(request_region(...)notfailed){
3
if(request_irq(...)notfailed)
4
return0;// success
5
free_region(...);
6
}
7
unregister_chardev(...);
8
}
9
return-EIO;
Das tut das Gleiche, ist nur halb so lang, kommt ohne Gotos aus und ist
(zumindest für meinen Geschmack) um Welten leichter durchschaubar.
Hättest du in deiner Goto-Orgie wenigstens alle drei Abfragen gleich-
artig formuliert, dann wäre sie trotz der Gotos gut lesbar:
1
if(register_chardev(...)failed)
2
gotoout;
3
4
if(request_region(...)failed)
5
gotoout_region;
6
7
if(request_irq(...)failed)
8
gotoout_irq;
9
10
return0;// success
11
12
out_irq:
13
free_region(...);
14
out_region:
15
unregister_chardev(...);
16
out:
17
return-EIO;
Aber dein ursprüngliches Code-Fragment hat außerhalb des Tellers im
Ristorante wirklich nichts zu suchen =8-[
@ Yalu X. (yalu) (Moderator) schrieb über das goto-Beispiel
> Autsch! Das ist ja ein geradezu perfektes Paradebeispiel dafür, wie man> Gotos nicht benutzen sollte.
Herrlicher Beitrag! Applaus!
;)
Warum denkt eigentlich jeder, daß BASIC immer was mit GOTO zu tun hat??!
;-)
Ich benutze GOTO seit ca. 20 Jahren nicht mehr. Denn ab ca. 1989 habe
ich PASCAL gelernt und halte mich auch beim Proggen in BASIC an diesen
Stil. Man kann auch in BASIC sauber (!!!) programmieren. Über den
"aufgeblähten" Endcode möchte ich mich nicht streiten. Es mag sicher
kleiner gehen!
Ich habe großen Respekt vor den Leuten, die C können. Ich habe mehrere
Versuche gestartet, es zu lernen. Also möchte ich mich nicht als
lernresitent bezeichnen. Leider fehlt mir einfach die Zeit, es praktisch
zu lernen und immer nur lesen bringt leider nix. Falscher Ansatz,
richtig, leider fehlt trotzdem die Zeit!
Neben PASCAL habe ich einiges an Maschinensprache, S5, S7 und andere
Sachen gelernt und auch im Beruf genutzt. Privat nutze ich schon sei
1983 BASIC. Danach VisualBASIC und seit 2007 BASCOM. Mit allen Derivaten
habe ich schon große Projekte gestemmt und wenn man sich an Disziplin
beim Proggen hält, dann sind die Programme ebenso gut, wie in anderen
Sprachen.
Sind wir doch mal ehrlich. Solange es nicht um berufliches geht, dann
zählt doch einfach, daß es funktioniert, daß es absturzfrei
funktioniert, einfach passt und daß man mit Freude ans Ziel kommt.
Macht uns "kleine BASCOM-User" doch nicht immer so fertig! (Schreibe
dies mit einem kleinen Schmunzeln, es hat ja auch schon viel positive
Kommentare hier gegeben. Was ich NICHT GEDACHT hätte! ;-)
Gruß Hackes
Ich finde das reflexhafte Basic-Bashing einfach nur dumm. Man kann in
jeder Programmiersprache mistigen Code frickeln und man kann es genau so
gut ordentlich machen. Die Basic-Gegner tun immer so, als müsse man
zwanghaft den sog. Spaghetti-Code fabrizieren - das kann eigentlich nur
aus ihren eigenen Erinnerungen stammen oder es ist einfach nur
nachgeplappert.
Ich möchte bei dieser Gelegenheit mal auf einen anderen Basic-Dialekt
hinweisen, noch dazu vollkommen kostenlos und sogar mit OO-Ansatz:
LunaAVR.
http://avr.myluna.de/doku.php?id=de:start
Es ist quasi ein RealBasic-Clone (fortschrittliches VB) für Windows,
Linux und MacOSX. Vor Allem letzteres (noch nicht ganz fertig) dürfte
ein wirkliches Alleinstellungsmerkmal sein.
Ich weiss jetzt nicht wie lange ich das schon verfolge, aber irgendwann
kann vielleicht jeder "programmieren":
http://avrtools.no/
So etwas als Vorlage/Bausteine und jede Programmiersprache wird zum
Kinderspiel...
BASCOM ist für die Realisierung einfacher Projekte gut geeignet.
Zeitkritische Funktionen können sehr einfach mit Inline Assembler
eingefügt werden. Installation und Bedienung der IDE ist kein Akt. Bin
mit dem TO auf einer Linie.
Für mich ist es keine Philosophie, welche Programmiersprache benutzt
wird, sondern welche mich zu meinem Ziel führt und für mich als
Hobbybastler hat bis jetzt noch alles mit BASCOM und Inline Assembler
funktioniert.
µC Programmierung ist für mich keine Frage der Sprache, sondern wie
krieg ich ihm beigebracht was ich will. Da war das Wühlen in
Datenblättern vordringlicher als der Kampf mit IDE und Zeichensprache
lernen.
Der Einstieg fiel mir sehr leicht und ich kann die Leute verstehen, die
C lernen mußten oder auch ohne Not gelernt haben, daß es ihnen ein Dorn
im Auge ist, wenn man als Anfänger auch ohne langen Lernprozess und
geringen Frustrationsfaktor zum Ziel kommt.
Falls ich mit BASCOM irgendwann nicht weiterkommen sollte, wird halt C
genommen oder gleich Assembler. Übrigens ist mir nicht klar, warum die
BASCOM-Verächter und C-Verfechter nicht alle Assembler nehmen. Jeder hat
halt seine Grenzen. :-)
Ob man nun C aus beruflichen Gründen lernen muß(te) oder weil es alle
machen oder weil man sich damit scheinbar über die Hobbyentwickler
erhebt - man nimmt das, mit dem man klarkommt und einem zum Ziel führt.
Man nimmt doch auch keinen XMEGA wenn ein Tiny reicht.
Frank schrieb:> Ich möchte bei dieser Gelegenheit mal auf einen anderen Basic-Dialekt> hinweisen, noch dazu vollkommen kostenlos und sogar mit OO-Ansatz:> LunaAVR.
Kenne ich, ich helfe Richard da ab und zu etwas mit (Testen etc).
Mit Luna habe ich die ersten Gehversuche gemacht, Richard hat mich
auch dazu gebracht mich wieder mit uCs zu beschäftigen.
Luna ist ideal für die ersten Experimente und für Anfänger.
Mich engt es ein, es fehlen genau diese Includefiles, die Syntax
kann ich nicht ab, es fehlt einfach die Präzision wie ich sie von
C her kenne.
Ich glaube auch nicht, daß Luna "einfacher" wie C ist. Prinzipiell
kann ich am Anfang einfacher Unkenntnis der Hardware überdecken, das
relativiert sich dann aber. Die ersten Erfolgserlebnisse hat man
mit Luna definitiv VIEL schneller wie bei C.
PS: Ich habe mal mit eingetippten Hexcodes angefangen, Assembler,
C, GWBASIC würg, dBASE, PHP etc.
C ist wie ein klarer Schnaps, ehrlich und kernig und dabei transparent.
BASIC wie zuckersüßes Likörchen ("Schlüpferstürmer").
In einem anderen Forum wurde mal der erzeugte Code von C und Bascom
zerpflückt. Resultat war, dass C oftmals mehr Anweisungen und damit CPU
zeit verbraucht als Bascom.
Was viele hier mit Bascom ist langsam immer wieder verwechseln ist, dass
Bascom kein Interpreter ist der auf der CPU läuft, sondern ein Compiler.
Ich nutze Bascom ausschließlich und habe ab und zu schon sachen gehabt
die sich in C sicher eleganter hätten lösen lassen. Einfach weil die
Sprache mächtiger ist. Was der Compiler hinterher daraus macht ist
allerdings die Frage. Schade das es noch kein Bascom für ARM gibt :-(
Danke für die zahlreichen, teilweise sehr guten Kommentare!
Mir kommt vor, dass die Bascom Befürworter etwas mehr Weitsicht haben,
als
die C Progger Freaks, die zwanghaft an dem 40 Jahre alten C festhalten
wollen.
Wenn es mit der zunehmenden Komplexität der MCs so weiter geht (siehe
XMegas), reicht C in dieser Form nicht mehr aus. Es sei denn, man ist
Masochist oder die Entwicklungszeit spielt keine Rolle.
Ich würde mich als "Generalisten" bezeichnen und habe kein Problem, auch
mit Bascom was zu machen. Ich entwickle auch in C (je nach Projekt) und
schätze es sehr.
Trotz gutem Supports von Atmel war das letzte Aufsetzen eine XMegas ein
tagelanges Unterfangen. Der Code (von Atmel) ist zB. durch die neue
Schreibweise der Registerzuweisungen schon fast unleserlich geworden.
Beispiel:
n=(CLK.PSCTRL & (~(CLK_PSADIV_gm | CLK_PSBCDIV1_bm | CLK_PSBCDIV0_bm)))
|
CLK_PSADIV_1_gc | CLK_PSBCDIV_1_1_gc;
Einfach zu wartender Code? Portierbar? Ist das die Zukunft? Danke
Bascom!
Schöne Grüße Duplo
Sebastian Heyn schrieb:> In einem anderen Forum wurde mal der erzeugte Code von C und Bascom> zerpflückt. Resultat war, dass C oftmals mehr Anweisungen und damit CPU> zeit verbraucht als Bascom.
Zeig mal den Link.
Gruß Oliver
In unserer Fa. bin ich für die Hardware zuständig.
Wenn der erste Prototyp gelötet ist brauche ich mit Bascom meist keinen
halben Tag um alle Funktionen zu testen.
Danach bekommts der C- ler, der soll sich dann damit abplagen.
Ich bin auch von Bascom zu C umgestiegen da ich irgendwann Register
direkt setzen musste weil Bascom den Chip nicht richtig integriert
hatte. Ich glaube das war Attiny26 und PWM oder sowas.
Für ganz einfach Sachen nehme ich Arduino und das Teensy Board. Da
brauche ich nicht mal eine ISP Buchse auflöten und kann für verschiedene
Dinge direkt auf Bibliotheken zugreifen. Kommunikation über USB ist auch
praktisch!
Gruss
Bernd
Hi,
> Notwendig waren 3 UARTs,SPI,1Wire und I2C. Das Brutale war dann noch das> Management einer SD Card.>> In C mit Studio 6 eine wissenschaftliche Arbeit und eigentlich unmöglich> unter 40 Stunden. Mit Bascom war das ohne Kenntnis der Umgebung in 2> Tagen erledigt. Respekt vor den Entwicklern.
Wäre auch in C kein Problem, wenn man konsequent während seines
'Entwicklerdaseins' konfigurierbare Bibliotheken für immer
wiederkehrende Funktionalitäten aufgebaut hat. UART, I2C, SPI schreit
förmlich nach Bibliothek :-)
> Was denkt ihr über Bascom?
Code ist leider nicht portierbar...
Gruß
Neil
Neulich wollte ich in Bascom mal wieder das GOTO benutzen, aber es ging
nicht mehr. Durch das jahrelange Nichtbenutzen war es verrostet und
seine
Lager waren fest. Ich mußte erst mal eine Supp-Routine mit WD40
ausführen,
um GOTO wieder gängig zu kriegen. Schwerfällig hüpfte es zu einer
Sprung-
marke, die ich ihm vorgegeben hatte. Die Distanz war aber wohl zu groß,
GOTO brach sich das Fußgelenk und blieb jammernd auf dem Stack liegen.
Es hoffte darauf, daß ich seinen Rücksprung organisieren würde. Ich
dachte:
Warte Du nur eine WHILE, bis ich mein Auto WEND.....
;-)
MfG Paul
Duplo schrieb:> Wenn es mit der zunehmenden Komplexität der MCs so weiter geht (siehe> XMegas), reicht C in dieser Form nicht mehr aus. Es sei denn, man ist> Masochist oder die Entwicklungszeit spielt keine Rolle.
Was hat die komplexitaet eines uC mit der Programmiersprache zu tun?
Nichts.
Den die Peripherie eines uC spricht man mit den dafuer erstellten
Bibliotheken an. Und diese muessen egal in welcher Sprache auch immer
erstmal erstellt werden. Das die in Bascom teilweise in rudimentaerer
Form dabei sind hat erstmal nichts mit der Sprache an sich zu tun. Hat
dann die vorhandene Funktion dann nicht die gewuenschte Eigenschaft dann
stehen doch die meisten Bascom Programmierer erstmal auf dem Schlauch.
Wenn man sich um die Libs nicht zu stoeren braucht dann kann ich auch in
5 Minuten ein C Programm auf einen x-beliebigen Controller am laufen
bringen.
Man muss klar unterscheiden was macht die Sprache aus und was sind
Bibliotheksfunktionen. Und das ist nunmal in C klar unterschieden. Die
Sprache C kennt an sich keine Ein/Ausgabefunktionen. Die sind alle in
Biblioteken enthalten.
Und von der Komplexitaet ist eine PC-CPU sammt Peripherie wohl
wesentlich aufwendiger als ein uC. Und trotzdem kann man ihn in C/C++
einfach programmieren.
Dazu kommt noch, daß der C-Source-Code vieler libs frei verfügbar ist.
Ist da einen Macke drin kann ich (wenigstens theoretisch) etwas
machen.
(zB SQLite)
Das Maß an Unfähigkeit, mangelndem Verständnis asynchroner Abläufe
u.s.w. korreliert gut mit Basic-Programmierern.
Die haben es aus dem Grund weil sie es nicht geschafft haben eine
analytischere Sprache wie C/C++ zu beherrschen auch nicht geschafft ein
Verständnis dafür zu entwickeln.
Sie programmieren dann ganz schnell eine GUI die schick aussieht aber
dahinter wie scheisse funktioniert, viele konzeptionelle Fehler hat und
dauernd abstürzt. Schuld ist dann die Hardware.
D.h. der vermeintliche Zeit und Kostenvorteil ist eine Illusion.
Solche Leute gibt es auch in C/C++, aber besser getarnt.
Yalu X. schrieb:>> Autsch! Das ist ja ein geradezu perfektes Paradebeispiel dafür, wie man> Gotos nicht benutzen sollte. Warum schreibst du nicht einfach
Ja, das ist das Problem wenn man zu später Stunde einfach irgendetwas
aus dem Netz hinrotzt ohne das Hirn einzuschalten.
Dann halt mal ein reales Beispiel aus der eigenen Feder:
Tim T. schrieb:> Dann halt mal ein reales Beispiel aus der eigenen Feder:
Manchmal geht es nicht ohne (und macht ein Programm übersichtlicher).
GOTO war halt in Basic schon immer für Anfänger attraktiv und
hat sich so irgendwie festgesetzt, nebenbei gibt es in Assembler
auch Jumps. In BASIC führt es aber regelmäßig zu Spaghetticode.
Ich sollte mal so ein Spaghetti-Basic-Teil sanieren, es war nicht
mehr möglich. Neuschreiben in C brachte einen Performancegewinn
Faktor 2000 (!). Ohne goto (ok, war GWBASIC).
Das ist echtes Popcorn Kino hier.
Der erste Basicfreak sagt: Basic ist die Mutter aller
Programmiersprachen.
Sag mir doch mal wie alt IBM Assembler ist, wie alt Cobol, ...
Der nächste Basicfreak sagt: C ist schon 40 Jahre alt, kann also nix
mehr taugen.
Wann wurde im Commodore 4008 Basic ins ROM gebrannt? War das überhaupt
der erste?
Der dritte bringt ein C Beispiel für Goto vor das ihm in 5 Minuten als
lausiger Code zerplückt wird und gibt dann zu das habe er ja auch aus
dem Internet "hingerotzt".
Leute Leute, damit beweist ihr nur eines, nämlich eure geballte
Inkompetenz.
Zum Glück gibt es auch Basic Programmierer die sowas nicht nötig haben.
Eine Frage:
In welcher Sprache wurde eigentlich Bascom geschrieben?
Joachim Drechsel schrieb:>> Manchmal geht es nicht ohne (und macht ein Programm übersichtlicher).
Es geht immer ohne, wird nur beliebig unübersichtlich.
> GOTO war halt in Basic schon immer für Anfänger attraktiv und> hat sich so irgendwie festgesetzt, nebenbei gibt es in Assembler> auch Jumps. In BASIC führt es aber regelmäßig zu Spaghetticode.
Habe auch mit Basic auf einem C64 das Programmieren angefangen,
allerdings bin ich nie mit der Sprache warm geworden. Das war später mit
Pascal und C was ganz anderes. Dort wurde man irgendwie zu besserem Code
gezwungen.
Bei Assembler fehlt mir für größere Sachen einfach der Gesamtüberblick,
brauche dafür zu viel Papier um den ganzen Kram nachzuhalten und es geht
dem Gefühl nach dann auch in Richtung Spaghetticode.
> Ich sollte mal so ein Spaghetti-Basic-Teil sanieren, es war nicht> mehr möglich. Neuschreiben in C brachte einen Performancegewinn> Faktor 2000 (!). Ohne goto (ok, war GWBASIC).
Nicht das ich Basic hier in Schutz nehmen will, aber sowas kann einem
bei allen Programmiersprachen begegnen.
Ich habe zwar nicht alle Postings gelesen...aber ich kann nur soviel
sagen, weil ich keine Ahnung habe und ich weiss nicht was ich tue, das
ich auch seit einem Jahr Bascom benutze und mit 0 Programmierkenntnisse
gestartet habe, daß meine RGBs faden, Leds blinken und die Uhren
ticken...
Ich weiss nicht ob man das Ohmsches Gesetz ißt oder trinkt...und damit
habe für einigen einen Gefallen getan. Freut mich.
duplo schrieb:> Wenn ich mir als Assembler und C Fan
Und ich bin Fußballfan. Aber zum selber kicken reicht es nur für den
Kartoffelacker. Da ist natürlich die Allianz-Arena dran schuld.
mfg.
Udo Schmitt schrieb:> Leute Leute, damit beweist ihr nur eines, nämlich eure geballte> Inkompetenz.
Was würde denn in so einem Thread Kompetenz ausdrücken? Fürs allgemeine
Blafasel bei diesem Thema reicht minimale Restaktivität aus, eventuell
gibts bald mal ein Bot dafür (in BASIC oder so) geschrieben. Ein Namen
hätte ich auch schon dafür BBB - Bascom Bashing Bot.
> Zum Glück gibt es auch Basic Programmierer die sowas nicht nötig haben.
Nö, die haben ja bald ihren Bot.
>> Eine Frage:>> In welcher Sprache wurde eigentlich Bascom geschrieben?
Vom Aussehen her würde ich auf Delphi tippen.
Duplo schrieb:> Mir kommt vor, dass die Bascom Befürworter etwas mehr Weitsicht haben,> als die C Progger Freaks,
Wie kommst du denn darauf?
Weitsicht bzgl. der Hardwareplattform führt weg von Bascom, da die
Mikrocontrollerwelt ja nicht nur aus AVRs besteht.
Weitsicht bzgl. des beruflichen Werdegangs führt ebenfalls weg von
Bascom, da dieses fast nirgends in der Industrie eingesetzt wird.
> die zwanghaft an dem 40 Jahre alten C festhalten wollen.
Naja, Basic ist noch 8 Jahre älter :)
> Wenn es mit der zunehmenden Komplexität der MCs so weiter geht (siehe> XMegas), reicht C in dieser Form nicht mehr aus. Es sei denn, man ist> Masochist oder die Entwicklungszeit spielt keine Rolle.
Hmm, C hat sogar für noch sehr viel komplexere Hardware als die XMegas
ausgereicht.
Falls auch die Anwendungen deutlich komplexer und größer werden, kann
man ja darüber nachdenken, auf einen der Nachfolger von C (C++, D, Java,
C# ...) umzusteigen. Mit "deutlich komplexer und größer" meine ich hier
aber Anwendungen, die weit jenseits der Möglichkeiten eines AVR oder
XMega liegen, so dass sich die Frage, ob Bascom oder nicht, sowieso
nicht mehr stellt.
Ich möchte aber Bascom keinem madig machen. Jeder sollte das benutzen,
wo er denkt, dass er damit am weitesten kommt.
Tim T. schrieb:> Dann halt mal ein reales Beispiel aus der eigenen Feder:
Ja, das sieht schon deutlich mehr nach sinnvollen Gotos aus. Gotos sind
vor allem dort sinnvoll, wo von verschiedenen Stellen in verschachteltem
Code das gleiche Ziel angesprungen werden soll (typisch in Fehlerbehand-
lungen). Bei deinem neuen Beispiel ist dieses Ziel das Label cleanup. In
deinem ersten Beispiel war dieser Fall nicht gegeben.
Thomas der Bastler schrieb:> Ich weiss nicht ob man das Ohmsches Gesetz ißt oder trinkt...und damit> habe für einigen einen Gefallen getan. Freut mich.
Dunkel deiner Rede Sinn ist...
Tim T. schrieb:> Thomas der Bastler schrieb:>> Ich weiss nicht ob man das Ohmsches Gesetz ißt oder trinkt...und damit>> habe für einigen einen Gefallen getan. Freut mich.>> Dunkel deiner Rede Sinn ist...
Thomas ist glaube ich stolz darauf, daß er trotz diversen netten und
auch weniger netten Hinweisen sich immer noch erfolgreich dagegen wehrst
absolute Grundlagen zu lernen.
Yalu X. schrieb:> Ja, das sieht schon deutlich mehr nach sinnvollen Gotos aus. Gotos sind> vor allem dort sinnvoll, wo von verschiedenen Stellen in verschachteltem> Code das gleiche Ziel angesprungen werden soll (typisch in Fehlerbehand-> lungen). Bei deinem neuen Beispiel ist dieses Ziel das Label cleanup. In> deinem ersten Beispiel war dieser Fall nicht gegeben.
Im wesentlichen wird goto immer im gleichen Konstrukt verwendet, um aus
einer Funktion herauszuspringen und dabei alle bis dahin durchgeführten
Initialisierungen wieder rückgängig zu machen. Ohne gotos wären die
Deinitialisierungen entweder redundant vorhanden und bei Änderungen
würde immer etwas vergessen zu ändern oder es wären sehr
unübersichtliche Schleifenkonstrukte erforderlich.
Yalu X. schrieb:> Lueger schrieb:>> Basic war und ist sehr gut und die Mutter aller Programmiersprachen.>> Nein, das ist Lisp :)
Das ist FORTRAN, Ihr Noobs. ;-)
duplo schrieb:> unmöglich> unter 40 Stunden. Mit Bascom war das ohne Kenntnis der Umgebung in 2> Tagen erledigt
2 Tage = 48 Studen, wo ist das Problem?
Tim T. schrieb:> Im wesentlichen wird goto immer im gleichen Konstrukt verwendet, um aus> einer Funktion herauszuspringen und dabei alle bis dahin durchgeführten> Initialisierungen wieder rückgängig zu machen. Ohne gotos wären die> Deinitialisierungen entweder redundant vorhanden und bei Änderungen> würde immer etwas vergessen zu ändern oder es wären sehr> unübersichtliche Schleifenkonstrukte erforderlich.
Na ja eine Dummy Schleife mit break und dann am Ende alle Zeiger die
NICHT mehr null sind entsprechend freigeben ist absolut nicht
unübbersichtlich.
Trotz allem ist das eine absolut legitime GOTO Anwendung, in Basic und
in C.
In moderneren Sprachen benutzt man Konstrukte wie try ... finally
Joachim Drechsel schrieb:> Mich engt es ein, es fehlen genau diese Includefiles, die Syntax> kann ich nicht ab, es fehlt einfach die Präzision wie ich sie von> C her kenne.
wo du aber ehrlich sein musst ist, dass es zum Großteil aber auch an der
eigenen Abneigung liegt. Technisch gesehen, ist es mit dieser Sprache
möglich so präziese zu sein wie mit C. Includes sind ebenso vorhanden
wie Strukturen usw. Bedenke das der Entwickler hier offensichtlich viele
hilfreiche Ausdrücke verschiedener Sprachen implemeniert hat. Der
einfachste Beispiel ist das praktische Bitshiften mit << und >>, wobei
das sogar mit Variablen funktioniert.
> Ich glaube auch nicht, daß Luna "einfacher" wie C ist. Prinzipiell> kann ich am Anfang einfacher Unkenntnis der Hardware überdecken, das> relativiert sich dann aber. Die ersten Erfolgserlebnisse hat man> mit Luna definitiv VIEL schneller wie bei C.
Meine persönliche Meinung dazu ist: es fehlen hier und dort noch kleine
Ecken, im Großen und Ganzen muss ich aber meine Hochachtung aussprechen.
Der erzeugte Code ist eine sinnvolle Kombination aus Geschwindigkeit und
Codegröße, die Syntax ist leicht verständlich, der OO-Ansatz ist eine
sinnvolle Mischung aus prozedual und objektorientiert und die IDE ist
praktikabel, flink und übersichtlich. Wenn ich C nicht mag, würde ich
diese Sprache wählen.
Ich muss im Übrigen gestehen, das ich ein fast militanter
Assembler-Programmierer bin, erwische mich jedoch seit dem Erscheinen
von Luna neuerdings überproportional oft bei der Verwendung derselben.
Wenn, wie Frank sagt, möglicherweise auch zukünftig eine MacOS-Version
erscheinen sollte, dürfte das ziemlig einmalig sein. Die armen Mac-User
haben da keine sonderlich große Auswahl.
Ehrhardt
Jetzt nicht speziell an Yalu, ich möchte nur den Faden aufgreifen
>> Wenn es mit der zunehmenden Komplexität der MCs so weiter geht (siehe>> XMegas), reicht C in dieser Form nicht mehr aus. Es sei denn, man ist>> Masochist oder die Entwicklungszeit spielt keine Rolle.>> Hmm, C hat sogar für noch sehr viel komplexere Hardware als die XMegas> ausgereicht.
Hier werden doch Äpfel mit Birnen verglichen.
Was ist denn das Tolle an BASCOM? Doch nicht die Sprache an sich. Was
mir sauer aufstösst, ist zb das man Expressions auf mehrere Zeilen
aufdröseln muss. Das hat zwar gewisse Vorteile wenn es um die Frage der
Operator-Reihenfolge bzw. automatische Konversionen geht (wie man im
Forum sieht: ein Dauerbrenner), hat man diesen Themenkreis in C aber
erst mal intus, dann ist es kein Problem mehr. Nichts desto Trotz kann
ich in BASCOM keine 'komplexeren' Expressions in einer Zeile schreiben.
(OK, die IDE könnten sie auch mal ein wenig pimpen. Automatische
Einrückung würde vielen Programmen guttun.
Dem Syntaxparser kann seine Vergangenheit des zeilenweisen
Syntaxcheckens auch nicht verleugnen und ist daher keine große Hilfe,
wenn es um strukturierte Progammierung geht.
etc. etc. In Summe aber: alles nicht so wild.
)
Nein, das Tolle an BASCOM ist, dass es die Hardware der AVR (und nicht
nur die) in weitgehend abstrahierter Form als Sprachkonstrukt zur
Verfügung stellt. Und soweit ich weiß, kann man an dieser Stelle die
"Sprache" auch noch mit externen Komponenten pimpen. GLCD wurden meines
Wissens so eingebunden.
Das alles hat den Vorteil, dass sich Neulinge erst mal um viele Dinge
nicht kümmern müssen.
Aber: Das ist kein Vor- oder Nachteil für C. Wenn es gelingen würde,
eine Standard-'Lib' zusammenzustellen, in der ebenfalls für die
häufigsten Anwendungsfälle fertige Codemodule zur Verfügung stehen, dann
ist man mit C genauso schnell wie mit BASCOM, was das Hochziehen einer
App angeht.
Das wir diese Codemodule nicht haben hat keine technischen Gründe
sondern ist ein Politikum. 30 oder 40 Programmierer kriegst du nun mal
nicht unter einen Hut ohne dass es zu Kompetenzgerangel kommt, weil
jeder seine Lösung als die bessere ansieht, die allen anderen überlegen
ist. (Und wie man an BASCOM sieht, ist es gar nicht sooo wichtig, immer
die allerbeste Lösung zu haben. EINE Lösung die zuverlässig ist, würde
schon reichen)
Da hat es BASCOM ein wenig leichter. Die gibt es 1 Firma und die macht
die Vorgabe.
Ach, und noch was.
Hütet euch bitte auch davor, dass was wir hier im Forum von BASCOM bzw.
an BASCOM-Fragen sehen, als symptomatisch anzusehen.
Was wir hier mitkriegen, stammt zum großen Teil von Leuten, für die eine
Aufforderung doch mal in die Hilfe zu sehen, schon fast einer
'Einschränkung der persönlichen Freiheit' gleichkommt. Was natürlich
kategorisch abgelehnt wird.
Ehrhardt Balstein schrieb:> Wenn, wie Frank sagt, möglicherweise auch zukünftig eine MacOS-Version> erscheinen sollte, dürfte das ziemlig einmalig sein. Die armen Mac-User> haben da keine sonderlich große Auswahl.
Frank ? Ich dachte, Richard ...
Karl Heinz Buchegger schrieb:> Aber: Das ist kein Vor- oder Nachteil für C. Wenn es gelingen würde,> eine Standard-'Lib' zusammenzustellen, in der ebenfalls für die> häufigsten Anwendungsfälle fertige Codemodule zur Verfügung stehen, dann> ist man mit C genauso schnell wie mit BASCOM, was das Hochziehen einer> App angeht.
Genau das ist es, was die Jungs von Arduino / Wiring machen.
Na klaro, wenn man im Leben noch nichts anderes programmiert hat, als
ein Lauflicht dann kommt einem jede Sprache dafür gut genug vor. Es geht
nicht um die trivialen Konstrukte. eine for schleife ist eine for
schleife, egal wie man das in C oder BASIC schreibt. Und das Bascom für
die AVRs eine große lib mitbringt ist ja schön, sagt aber über die
Sprache halt nix aus.
Ich gebe zu, Bascom im speziellen kenne ich nicht sehr gut. Lerne aber
gerne dazu. Also schauen wir uns doch mal zwei Beispiele an:
1.)
Gibt es in BASCOM die möglichkeit, eine Referenz auf eine Funktion zu
übergeben? Also eine sog. Callback Funktion zu implementieren? Und wie
sieht das dann aus? Falls BASCOM OO kann, ist die Antwort natürlich
einfach. C kann kein OO, aber dafür gibts Funktionspointer.
In einem aktuellen Projekt benötige ich eine Callback Funktion. Eine lib
verrichtet ihren Dienst, und muss ab und zu, bei speziellen Kommandos
die Kontrolle abgeben.
In der lib sieht das so aus:
Das Programm welches die lib verwendet macht das so:
1
voidspecial_mb_command(uint8_tcmd){
2
//Tu was
3
}
4
5
intmain(){
6
mb_setCommandCallback(&special_mb_command);
7
}
2.)
In C kann man alle Datenstrukturen gleich behandeln. Das ist wichtig,
wenn man sie z.B. lediglich Byteweise speichern oder lesen oder
versendet/empfangen möchte. Ich will nicht jede Variable einzeln
behandeln, ich will den ganzen Haufen nehmen und einfach byte für byte
was damit machen.
Ein Gerät kann via PC parametrisiert werden. Dazu gibt es einige Config
Variablen, welche in einem Struct (Config_t) stecken.
Die Funktionen zum lesen und schreiben des struct aus und in den eeprom
halten sich in Grenzen:
Ähnlich kompakt sind die Funktionen zum senden und empfangen der Config
via serielle Schnittstelle. Man beachte dass hierbei das struct selber
imd die darin definierten Variablen, gar keine Rolle spielen. Eine
Änderung des structs, zieht keine Änderung in den genannten Funktionen
nach sich.
Wie sehen die Korrespondierenden Lösungen in BASCOM aus?
gruß cyblord
Karl Heinz Buchegger schrieb:> Aber: Das ist kein Vor- oder Nachteil für C. Wenn es gelingen würde,> eine Standard-'Lib' zusammenzustellen, in der ebenfalls für die> häufigsten Anwendungsfälle fertige Codemodule zur Verfügung stehen, dann> ist man mit C genauso schnell wie mit BASCOM, was das Hochziehen einer> App angeht.
Ich würde so eine "Standard-Lib" in C auch sehr begrüßen, wäre sofort
bei der Entwicklung mit dabei, wenn sich noch eine Handvoll anderer
Leute beteiligen würden.
> Das wir diese Codemodule nicht haben hat keine technischen Gründe> sondern ist ein Politikum. 30 oder 40 Programmierer kriegst du nun mal> nicht unter einen Hut ohne dass es zu Kompetenzgerangel kommt, weil> jeder seine Lösung als die bessere ansieht, die allen anderen überlegen> ist.
Das sehe ich als kleineres Problem an. Als damaliger Gründer des
fli4l-Projekts kann ich dazu nur sagen, dass es einen geben muss, der
das Grobkonzept vorgibt und bei Streitfragen entscheidet und dessen
Meinung von allen anderen akzeptiert und mitgetragen wird. Dann klappt
das schon. Beim fli4l-Projekt hat das sogar mit bis zu 70 (Haupt- und
Neben-)Entwicklern funktioniert. Jeder im Team findet seine Nische, wo
er sich austoben kann.
Gruß,
Frank
Joachim Drechsel schrieb:> Ehrhardt Balstein schrieb:>> Wenn, wie Frank sagt, möglicherweise auch zukünftig eine MacOS-Version>> erscheinen sollte, dürfte das ziemlig einmalig sein. Die armen Mac-User>> haben da keine sonderlich große Auswahl.>> Frank ? Ich dachte, Richard ...
der Beitrag stammt von einem Frank, ich nehme an ein Mac-User der das in
Zuammenarbeit testet
cyblord ---- schrieb:> Wie sehen die Korrespondierenden Lösungen in BASCOM aus?>
Ok, die EPROM Sache ist jetzt nicht so speziell, ist in BASCOM aber auch
kein Showstopper. Dort brauchst du keine eeprom_read_xxx Funktionen. Du
markierst die Variable als 'im EEPROM' und gut ists.
Die andere Sache, das musst du selber auch zugeben, ist dann schon etwas
speziell. Weil du das eben so brauchst.
Ich behaupte aber mal: Viele Programme brauchen solche Dinge gar nicht.
Um mit einem Tiny 2 RC-Signale zu mischen und wieder auf einen
Servoausgang zu legen, ist das alles nicht notwendig. Mit BASCOM ist das
trivial machbar (wenn auch nicht unbedingt optimal). Da hat dein
AVR_Studio noch nicht mal fertig gebootet, brennt der BASCOM Jünger
schon den Tiny. Muss man neidlos anerkennen.
Und viele Programme sind in dieser Komplexitäts-Kategorie.
BASCOM ist für mich wie ein Letherman. Klar: die 12 verschiedenen
Schraubendreher in der Werkstatt sind was anderes als die beiden am
Letherman. Klar, mit der Säge am Letherman wirst du ausser kleinen
Stücken nicht viel schneiden können, und die Feilen sind kein wirklicher
Ersatz für den Satz Schlüsselfeilen zu Hause. Aber trotzdem ist ein
Letherman nützlich, wenn man sich darauf besinnt, wozu er gedacht ist,
was er kann und wo seine Grenzen liegen.
Karl Heinz Buchegger schrieb:> Ok, die EPROM Sache ist jetzt nicht so speziell, ist in BASCOM aber auch> kein Showstopper. Dort brauchst du keine eeprom_read_xxx Funktionen. Du> markierst die Variable als 'im EEPROM' und gut ists.
Das speichern im eeprom war ein Beispiel. Es geht NICHT um das schreiben
ins eeprom. Ausserdem, wie sieht das in Bascom aus? Definiert man da
eine oder zwei Variablen? Also eine fürs Ram und eine für den EEPROm?
Und wie kontrolliert man wann ins eeprom geschrieben oder gelesen wird?
Ich möchte ja vielleicht nicht sofort alles im eeprom haben.
Wie siehts mit dem versenden/empfangen aus? Also mit dem Byteweisen
Zerpflücken? Und vorallem das gruppieren via struct? Zig Einzelvariablen
sind nicht so übersichtlich...
1
Config_tcfg;
2
3
voidsendConfig(){
4
for(inti=0;i<sizeof(Config_t);i++){
5
send(((uint8_t*)&cfg)[i]);
6
}
7
}
Vorallem was wenn man mehrere Konfig-Profile braucht? Dann reicht es 2x
Variablen vom Typ Config_t anzulegen. In Bascom???
1
typedefstructConfig{
2
uint8_tvar1;
3
uint16_tvar2;
4
char[10]string;
5
uint16_t[15]varArray;
6
}Config_t;
7
8
Config_tconfig1;
9
Config_tconfig2;
> Die andere Sache, das musst du selber auch zugeben, ist dann schon etwas >
speziell
Naja, also das übergeben von Funktionen als Parameter braucht man schon
öfters. Ist wie gesagt bei OO eigentlich standard, nur das siehts anders
aus.
Ausserdem las ich hier durchgehend, dass mit Bascom alles gehen würde,
was mit C auch geht. Ich las wenig davon dass Bascom beschränkt aber
einfach ist.
gruß cyblord
cyblord ---- schrieb:
Zum Thema 'Config'.
Keine Ahnung. Bin kein BASCOM Spezialist.
Ich habs ein paar mal gestartet, ein wenig damit gespielt und das wars
dann auch.
>> Die andere Sache, das musst du selber auch zugeben, ist dann schon etwas >> speziell> Naja, also das übergeben von Funktionen als Parameter braucht man schon> öfters.
Du brauchst das.
Derjenige, der einen Ersatz für die Steuerung seiner Waschmaschine
braucht, braucht das nicht.
Versteh mich nicht falsch: Ich sag ja nicht, dass du da jetzt hohe
Anforderungen stellst. Ich behaupte lediglich: die Mehrzahl der Leute,
die mit BASCOM arbeiten verspüren gar nicht den Drang dazu, sowas zu
machen. Sie brauchen es für ihre Projekte schlicht und ergreifend nicht.
Für den ist viel wichtiger, dass sein LCD aus dem Stand heraus
funktioniert und er mit 2 Tasten die Vorgabetemperatur für die
Gewächshausheizung, die er mit PWM anspricht, ändern kann. Und das alles
in weniger als 20 Zeilen Code.
> Ausserdem las ich hier durchgehend, dass mit Bascom alles gehen würde,> was mit C auch geht. Ich las wenig davon dass Bascom beschränkt aber> einfach ist.
Ist es aber. Dessen muss man sich bewusst sein.
BASCOM ist keine Universalsprache sondern speziell auf die Bedürfnisse
von Leuten abgestimmt, die µC programmieren. Alles andere wurde
abgespeckt. Wie gut es sich für größere Projekte eignet kann ich mangels
Erfahrung nicht beurteilen. Aber für kleinere Dinge ist es gar nicht mal
so schlecht.
Danke Karl Heinz, ich seh das ähnlich wie du.
Dazu kommt aber noch, dass eben jemand der noch nie richtig programmiert
hat, die Beschränktheit von Bascom gegenüber C gar nicht erkennt, aber
dafür immer schön draufhaut und sich lautstark fragt, wozu man das
uralte doofe C denn braucht. Und genau das ärgert mich.
Eventuell meldet sich ja noch ein BASCOM Programmierer und kann anhand
des Config Szenarios mal eine Lösung in BASCOM vorstellen? Ich wundere
mich ja schon ein wenig, bei allgemeinen Statements da oben reißt jeder
das Maul auf, aber wenns EINMAL sachlich und konkret wird, dann kommt
nix mehr.
gruß cyblord
cyblord ---- schrieb:> aber wenns EINMAL sachlich und konkret wird, dann kommt> nix mehr.
Echt jetzt mal, hat denn niemand ein konkretes "Config Szenario" in
Bascom?
Ich klinke mich mal einfach ein, mche vieles mit Bascom, ohne jetzt der
Vollprofi zu sein.
Was das Zerpflücken von Strings oder anderen variablen in Bytes angeht,
so geht das supereinfach.
Dim beliebiger_string as string *20
dim einzelne_bytes (20) as byte at beliebiger_string overlay
man kann nun mit dem String verfahren wie man will, hineinschreiben,
herauslesen, left, right, mid etc. alles machbar. Braucht man n
einzelnes Byte kann man das einfach bfragen als einzelne_bytes(x).
Geht genauso mit Word oder Single Variablen, dann einfach 2 Bytes bzw. 4
Bytes deklarieren.
Funktionen mit Rückgabewert gibts natürlich auch ...
declare function irgendeine_funktion (byval / byref
Wert_zur_funktion_hin as word) as single
function irgendeine_funktion (Wert_zur_funktion_hin)
local local_single as single
local_single = Wert_zur_funktion_hin*10
irgendeine_funktion = local_single
end function
Aufruf z.B. durch
Singlevariable = irgendeine_funktion(10)
EEPROM-Zugriffe gehen supereinfach, auch als eindimmensionales Array ...
dim eepromvariable (10) as eram byte
äquivalent gehts klaro auch mit word, single etc.
Aufruf einfach per
eepromvariable(1) = xy
cyblord ---- schrieb:> Es geht NICHT um das schreiben> ins eeprom. Ausserdem, wie sieht das in Bascom aus? Definiert man da> eine oder zwei Variablen? Also eine fürs Ram und eine für den EEPROm?> Und wie kontrolliert man wann ins eeprom geschrieben oder gelesen wird?> Ich möchte ja vielleicht nicht sofort alles im eeprom haben.> Wie siehts mit dem versenden/empfangen aus? Also mit dem Byteweisen> Zerpflücken? Und vorallem das gruppieren via struct? Zig Einzelvariablen> sind nicht so übersichtlich...
ich weiß jetzt nicht wie es in bascom funktioniert, in luna kann man
Strukturen nutzen, Beispiel Eeprom:
1
eeprom hallo
2
.db 100,200
3
.dw &h4711
4
.db 5,"hallo"
5
endeeprom
Zugriff über die Objektfunktionen:
1
a = hallo.ByteValue(1)
2
s = hallo.PString(4)
Im Arbeitsspeicher (aus den Examples):
1
struct point
2
byte x
3
byte y
4
endstruct
5
6
dim p(3) as point
7
8
p(0).x = 10
9
p(0).y = 20
Man sieht also, wenn man nicht weiß welche Möglichkeiten eine Sprache
speziell bietet, wird das oft zu schnell abgetan.
Gruß, Ehrhardt
Fhutdhb Ufzjjuz schrieb:> EEPROM-Zugriffe gehen supereinfach, auch als eindimmensionales Array ...
Dann wird man wohl sehr schnell die Schreibzyklenanzahl überschritten
haben, wenn man einfach so drauf los schreibt.
In C ist daher die übliche EEPROM-Nutzung, man legt eine beliebig
komplexe Struct (int, float, char* usw.) im SRAM an. Nach dem Reset wird
über den EEPROM eine CRC geprüft und dann in diese Struct kopiert.
Dann wir damit gearbeitet. Und nur auf Nutzeranforderung oder bei
Power-Fail-Erkennung wird zurück geschrieben.
Bei größeren Datensätzen erfolgt das im Interrupt, damit andere Prozesse
nicht lange blockiert werden.
Der EEPROM wir daher nicht ständig verschliessen, wie es aber bei
Gleichbehandlung mit SRAM der Fall wäre.
Ich habe auch einige kommerzielle Geräte, die sich nichts mehr merken
können. Vermutlich hat auch da der Programmierer die Schreibzyklenzahl
nicht beachtet.
Hier mal ein Beispiel:
Duplo schrieb:> Danke für die zahlreichen, teilweise sehr guten Kommentare!>>> Mir kommt vor, dass die Bascom Befürworter etwas mehr Weitsicht haben,> als> die C Progger Freaks, die zwanghaft an dem 40 Jahre alten C festhalten> wollen.>> Wenn es mit der zunehmenden Komplexität der MCs so weiter geht (siehe> XMegas), reicht C in dieser Form nicht mehr aus. Es sei denn, man ist> Masochist oder die Entwicklungszeit spielt keine Rolle.>> Ich würde mich als "Generalisten" bezeichnen
Also jetzt muß ich an dieser Stelle mal eingreifen:
1. Es interessiert niemanden was kleine Hobbybastler denken. Zählt ist
was in der Indujstrie verwendet wird. Die setzen in unseren
Breitengraden nun mal die Standarts und damit beschäftigen sich Menschen
hauptberuflich. Mit Weitsicht hat das mit Bascom nichts zu tun. Das hat
mit geringem Horizont zu tun. C bewährt sich seit vielen aJahren
millionenfach, wohingegen es BASCOM GENAUSOLANGE gibt, das sich aber
offensichtlich nicht durchgesetzt hat.
2. C ist so einfach - wer das nicht versteht - sorry der hat in ddiesem
Geschäft nichts zu suchen beruflich
3. Mit c und endsprechendnen Libs kann man alles realisieren. Machen tut
man das gleiche wie in Bascom nur, daß man bei Bascom keinen Zugriff
darauf hat. Wenn es sicherehitsrelevant ist, kann ich aber nicht
maschinenfern programmieren, sondern muß so maschinennah programmieren
wie möglich.
4. Ich möchte das Projekt sehen, daß man in Bascom realisieren kann aber
nicht in C mit gleichem aufwand. Das scheitert vielleicht an deinen
Kenntnissen aber nicht an den Möglichkeiten von C
Fhutdhb Ufzjjuz schrieb:>> Was das Zerpflücken von Strings oder anderen variablen in Bytes angeht,> so geht das supereinfach.>> Dim beliebiger_string as string *20> dim einzelne_bytes (20) as byte at beliebiger_string overlay
Ok das ist praktisch. Geht das auch mit zusammengesetzten Datentypen?
> Funktionen mit Rückgabewert gibts natürlich auch ...
Die gibts überall ;-)
> function irgendeine_funktion (Wert_zur_funktion_hin)> local local_single as single>> local_single = Wert_zur_funktion_hin*10> irgendeine_funktion = local_single> end function
Sorry kannst du das mal sauber und in [code] tags hinschreiben?
>> EEPROM-Zugriffe gehen supereinfach, auch als eindimmensionales Array ...>> dim eepromvariable (10) as eram byte
Das geht in C genauso. Wie wird der zugriff gesteuert? Wird bei jedem
schreiben auf diese Variable tatsächlich in den eeprom geschrieben?
gruß cyblord
Joachim Drechsel schrieb:> Fhutdhb Ufzjjuz schrieb:>> declare function irgendeine_funktion (byval / byref>> Wert_zur_funktion_hin as word) as single>> Äh wie ?
declare function ... alle Funktionen müssen deklariert werden.
Man kann Werte beim Funktionsaufruf mit übergeben, entweder
byval, dann wird der Wert kopiert, Änderungen des Wertes in der Funktion
bleiben nicht erhalten, oder
byref, dann wird der Pointer des Wertes mit übergeben, nicht der
eigentliche Wert, bei Änderungen des Übergabewertes in der Funktion
bleiben die dann bestehen.
as single am Ende bedeutet einfach, dass die Funktion als Rückgabewert
eine Singlevariable darstellt.
beispiel:
declare function irgendeine_funktion (byval Wert_zur_funktion_hin as
word) as single
dim ausgabesingle as single
dim uebergabe_wert as word
uebergabe_wert = 10
ausgabesingle = irgendeine_funktion(uebergabe_wert)
print uebergabe_wert
print ausgabesingle
do
loop
end
function irgendeine_funktion (Wert_zur_funktion_hin)
incr Wert_zur_funktion_hin
irgendeine_funktion=Wert_zur_funktion_hin * 2
end function
Hier wäre nun nach dem Funktionsaufruf uebergabe_wert immernoch 10 weil
byval, ausgabesingle wäre 22
declare function irgendeine_funktion (byREF Wert_zur_funktion_hin as
word) as single
dim ausgabesingle as single
dim uebergabe_wert as word
uebergabe_wert = 10
ausgabesingle = irgendeine_funktion(uebergabe_wert)
print uebergabe_wert
print ausgabesingle
do
loop
end
function irgendeine_funktion (Wert_zur_funktion_hin)
incr Wert_zur_funktion_hin
irgendeine_funktion=Wert_zur_funktion_hin * 2
end function
Hier wäre nun nach dem Funktionsaufruf uebergabe_wert 11 weil byref und
in der Funktion incr Wert_zur_funktion_hin, ausgabesingle wäre ebenfalls
22
Danke für dieses Exkurs in die "Tiefen" der By Value/By Reference
Problematik. Aber ich denke die kennen wir schon ;-) Darum gehts doch
gar nicht.
Ich dachte du wolltest die Übergabe von Funktionen als Parameter
darstellen. Also eine Funktion wird an eine Funktion übergeben.
ps: was hast du gegen die [code] tags?
cyblord ---- schrieb:> Fhutdhb Ufzjjuz schrieb:>>>> Was das Zerpflücken von Strings oder anderen variablen in Bytes angeht,>> so geht das supereinfach.>>>> Dim beliebiger_string as string *20>> dim einzelne_bytes (20) as byte at beliebiger_string overlay>> Ok das ist praktisch. Geht das auch mit zusammengesetzten Datentypen?
Bascom kennt keine zusammengesetzten Datentypen, Du kannst über ne
Single Variable 2 Word Variablen und 4 Byte variablen drüber legen z.B..
Structs gibts in Bascom nicht
>>> Funktionen mit Rückgabewert gibts natürlich auch ...> Die gibts überall ;-)>>>> function irgendeine_funktion (Wert_zur_funktion_hin)>> local local_single as single>>>> local_single = Wert_zur_funktion_hin*10>> irgendeine_funktion = local_single>> end function>> Sorry kannst du das mal sauber und in [code] tags hinschreiben?
kann µC-net basic code formatieren?
>>>> EEPROM-Zugriffe gehen supereinfach, auch als eindimmensionales Array ...>>>> dim eepromvariable (10) as eram byte> Das geht in C genauso. Wie wird der zugriff gesteuert? Wird bei jedem> schreiben auf diese Variable tatsächlich in den eeprom geschrieben?
ja, wird direkt keschrieben, mit allen Vor- und Nachteilen z.B. delay.
Würde ich aber nicht empfehlen ... auch ist damit recht vorsichtig
umzugehen. Die Abfrage einer ERAM-Variable in einem Interrupt hat mich
mal einige graue Haare gekostet, weil der EEPROM-Pointer da verschoben
wird, wird zeitgleich in der Mainloop auf das EEPROM zugegriffen gibt
das seltsame Effekte ...
Daher zu Programmstart die ERAM in SRAM kopieren und nur von Fall zu
Fall neu beschreiben wenn erforderlich.
Auch gehts zum beispiel nicht:
sramvariable = eramvariable * 10
das dagegen geht:
sramvariable = eramvariable
sramvariable = Singlevariable * 10
> gruß cyblord
Generell hat Bascom schon einige Pferdefüße ... Rechnen ist ein Graus
cyblord ---- schrieb:> Danke für dieses Exkurs in die "Tiefen" der By Value/By Reference> Problematik. Aber ich denke die kennen wir schon ;-) Darum gehts doch> gar nicht.
ok, dann hab ich da was missverstanden
> Ich dachte du wolltest die Übergabe von Funktionen als Parameter> darstellen. Also eine Funktion wird an eine Funktion übergeben.
ui, da muss ich passen, hab ich noch nicht probiert
> ps: was hast du gegen die [code] tags?
nix
Klar ist es besser,
so sieht man wenigstens wo code und wo text ist.
Gut es gibt in Bascom Übergabe by Reference, was schonmal gut ist, und
es gibt overlay = union in c.
Keine zusammengesetzten Datentypen, keine Funktionspointer.
Aber das heißt auch, dass beide meiner Szenarien da oben in Bascom so
nicht durchführbar sind?
Natürlich kann man Konfig Werte definieren, diese speicher/laden und
senden/empfangen. Aber der Code Aufwand wäre doch viel viel größer. Das
ganze wäre auch unübersichtlicher. Mehrere Konfigs gehen dann auch nur
schwerlich.
Das callback würde an sich gar nicht gehen.
gruß cyblord
cyblord ---- schrieb:> Klar ist es besser,> so sieht man wenigstens wo code und wo text ist.>>> Gut es gibt in Bascom Übergabe by Reference, was schonmal gut ist, und> es gibt overlay = union in c.> Keine zusammengesetzten Datentypen, keine Funktionspointer.
richtig
> Aber das heißt auch, dass beide meiner Szenarien da oben in Bascom so> nicht durchführbar sind?
richtig
> Natürlich kann man Konfig Werte definieren, diese speicher/laden und> senden/empfangen. Aber der Code Aufwand wäre doch viel viel größer. Das> ganze wäre auch unübersichtlicher. Mehrere Konfigs gehen dann auch nur> schwerlich.
?? hab ich nicht verstanden ... wie meinst Du das?
Du kannst z.B.
1
dimsinglevar(10)assingle
2
dimbytes(40)asbyteatsinglevar(1)overlay
oder
1
dimsinglevar(10)assingle
2
dimbytes_1(4)asbyteatsinglevar(1)overlay
3
dimbytes_2(4)asbyteatsinglevar(2)overlay
4
dimbytes_3(4)asbyteatsinglevar(3)overlay
5
etc.etc.
klar, kein Vergleich mit C
> Das callback würde an sich gar nicht gehen.
richtig
> gruß cyblord
cyblord ---- schrieb:> Das ist schon ne andere Übersichtlichkeit.
da hat du absolut recht, wenn man aber mit aussagekräftigen
Variablennamen arbeitet wie ich in meinem gerade erst verfassten
Protokollbeispiel kann man dem schon nahe kommen.
Neil schrieb:> Wäre auch in C kein Problem, wenn man konsequent während seines> 'Entwicklerdaseins' konfigurierbare Bibliotheken für immer> wiederkehrende Funktionalitäten aufgebaut hat.
Das kann man aber nur, wenn man sich als Entwickler nicht
weiterentwickelt.
Wenn man lernfähig ist, wird man zugegeben müssen, dass man Funktionen
von vor 10 Jahren so heute nicht mehr schreiben würde, weil man
effizientere Möglichkeiten gefunden hat. Warum sollte man dann auf dem
Stand von vor zehn Jahren stehende Bibliotheken nutzen?
Timm Thaler schrieb:> Wenn man lernfähig ist, wird man zugegeben müssen, dass man Funktionen> von vor 10 Jahren so heute nicht mehr schreiben würde, weil man> effizientere Möglichkeiten gefunden hat.
Welche und wieso?
Weil man vor 10 Jahren nicht programmieren konnte und heute noch genauso
vor sich hinwurschtelt? Es gibt auch Leute, die konnten schon vor 20
Jahren programmieren.
> Warum sollte man dann auf dem> Stand von vor zehn Jahren stehende Bibliotheken nutzen?
Weil 1+1 vor 10 Jahren 2 war, heute noch ist und in 11 Milliarden Jahren
auch noch sein wird.
mfg.
Ich hab schon beides ausgiebig benutzt. Was mir an Bascom gefällt:
schreib ein Programm, schreib zwischendrin ein paar Zeilen Assembler,
compilier das Ganze und Du kannst im Simulator (in der IDE) Schritt für
Schritt durch den Quelltext wandern, (nicht durch ein Make- Symbol oder
was auch immer file), egal ob Basic und Assembler-Zeile, und Du siehst
genau, wieviele Takte bzw. Mikro/Nanosekunden das dauert. Du brennst
das, und das Zeitverhalten ist exakt so!
Bei C musst Du (wenn Du sowas machen willst) immer die richtige
Compiler-Eistellung kennen, ckechen, dass nichts wegoptimiert wurde,
viele Compiler-Optionen kennen und auch noch richtig anwenden ...
Gerade wenn man die Chip-Performance voll ausreizen will, aber nicht
alles in Assembler schreiben will, hat das viel Charme.
Rainer Unsinn schrieb:> egal ob Basic und Assembler-Zeile, und Du siehst> genau, wieviele Takte bzw. Mikro/Nanosekunden das dauert.
Das machte mein Keil-Compiler schon vor 20 Jahren. Also schon ein alter
Hut.
Das Thema "Basic vs C" gibt es hier ja öfters, das letzte Mal sehr
ausführlich erst vor ein paar Monaten:
Beitrag "Basic und/bzw. vs - C Erfahrungsumfrage"
Die Einschränkungen von Bascom, die ich dort nannte
Beitrag "Re: Basic und/bzw. vs - C Erfahrungsumfrage"
(keine benutzerdefinierten Datenstrukturen, keine mehrdimensionalen
Arrays) zusammen mit dem Einwand von Karl Heinz:
Karl Heinz Buchegger schrieb:> Was mir sauer aufstösst, ist zb das man Expressions auf mehrere Zeilen> aufdröseln muss.
erinnern mich stark an das Basic des Sinclair ZX81 von 1981, das eben-
falls genau diese Einschränkungen hatte. Schon vor 30 Jahren wurde das
ZX81-Basic deswegen belächelt, da die Basic-Dialekte der Konkurrenz
(Apple und Commodore, TRS-80 usw.) mehrdimensionale Arrays und komplexe
Ausdrücke bereits beherrschten (Strukturen hatten aber auch diese nicht,
die kamen für Basic erst sehr viel später).
zum reparieren einer uhr benutze ich keinen hammer (z.b. bascom)
zum einschlagen eines nagels benutze ich keinen uhrmacherwerkzeug
(z.b."c")
zur mikro-chirugischen perfektion helfen beide nicht ( z.b. dann asm)
inquisitorische threads helfen da sicherlich nur zur selbstbestätigung.
ich nutze das werkzeug das zur aufgabe passt, das ist bascom, c oder
assembler (oder "xy"...). wenn ein programierer nicht die flexibilität
besitzt, seine aufgabe mit der problemorientierten sprache zu lösen, ist
es kein programierer. ich nenne dann so was fach-idiot.
bascom hat mir bei "quick-and-dirty's" schon oft geholfen. bascom wird
vom kunden gern aktzeptiert weil nachvollziehbar ohne spezialisten
wissen.
massstab ist die funktion und die stabilität.
bei den beiden anderen ebenen rede ich dann über "black-boxes". die
helfen zwar dem ersteller bei folgeaufträgen, aber dann bitte ohne
philosophische ansprüche die wahre lehre gefunden zu haben.
ps: ich mach das jetzt seit 40-jahren in einem grossbetrieb(>20000),
und ja, meine shift-taste ist defekt ;-)
Thomas Eckmann schrieb:> Weil 1+1 vor 10 Jahren 2 war, heute noch ist und in 11 Milliarden Jahren> auch noch sein wird.
Dummfug, 1+1 war auch schon immer 10, oder kann hier jemand nicht
programmieren?
Controllerregister können in Bascom natürlich auch direkt beschrieben
werden (und haben auch die gleichen Namen wie im Datenblatt)
Was mir bei solchen Diskussionen immer wieder auffällt ist, dass es eher
die C Programmierer sind, die "draufhauen" und Bascom schlechtreden.
Umgekehrt verneigen sich die meisten demütig, vor der geballten
Intelligenz.
PeterL schrieb:> Was mir bei solchen Diskussionen immer wieder auffällt ist, dass es eher> die C Programmierer sind, die "draufhauen" und Bascom schlechtreden.> Umgekehrt verneigen sich die meisten demütig, vor der geballten> Intelligenz.
Du vergleichst Äpfel mit Birnen.
C gibt es für alle Platformen, Bascom nur für ein winzigkleines Segment.
Wie man aus den Antworten sieht, haben die Bascom Befürworter hundert
Prozent mehr Weitsicht. Dabei handelt es sich um Leute, die meistens
über den Tellerrand hinausschauen und mehrere Sprachen beherschen. Sie
wählen einfach die zum Projekt passende Programmierumgebung aus und
verstehen sie gezielt einzusetzen. Projekterfolg gewiss.
Bibliotheken: Meine jahrelang entstandenen Bibliotheken kann ich alle
schrotten, weil der Einsatz von XMegas erforderlich ist...Danke C.
Mit Bascom habe ich das nicht einmal gemerkt, außer dass nach 1 Stunde
bereits die I2C-EEprom Funktionen liefen.
Auch Codevision geht hier einen etwas fortschrittlichern Weg mit dem
Codewizard.
Die, die in den C Bibliotheken das Paradies sehen, haben noch nie mit
einem XMega oder ARM gearbeitet. Wahrscheinlich nur mit Tinys. Die
laufen auch unter C schnell.
Ich hab einfach nicht immer Zeit und Lust, mich durch 500 Seiten
Datenblätter zu arbeiten. Das muß eine gute Programmierumgebung für mich
machen. Sonst ist sie für mich nicht zu gebrauchen.
Rico
Joachim Drechsel schrieb:> PeterL schrieb:>> Was mir bei solchen Diskussionen immer wieder auffällt ist, dass es eher>> die C Programmierer sind, die "draufhauen" und Bascom schlechtreden.>> Umgekehrt verneigen sich die meisten demütig, vor der geballten>> Intelligenz.>> Du vergleichst Äpfel mit Birnen.
Nee, ich denk' da hat er schon recht. Sobald ein Jünger des C es einmal
geschafft hat ein "Hello World" zu compilieren, führt das sofort zur
zwanghaften Einbildung etwas Besseres zu sein. Meist grundlos,
hundertfach im Forum vorhandenes gequältes C beweist das Gegenteil.
Die Hürden zum Einstieg sind in C höher, was natürlich auch einen
Vorteil hat, da der Nutzer eine höhere Leidensbereitschaft beweisen muss
und damit vorab 'ne gewisse Auslese stattfindet.
Andererseits sollte man nicht vergessen, dass ein einfacherer Einstieg
in eine Sprache potentiell zu einer stärkeren Verbreitung der Technik
führt, also etwas das auch Ziel dieses Forums ist.
Jedes Werkzeug hat gewisse Stärken, da muss man nehmen, was am besten
passt und am meisten persönlich zusagt. Wer ein Callback braucht, der
nimmt sich eine Sprache, die das erlaubt, braucht er's nicht, ist er
evtl. mit was Anderem besser bedient.
Nur, Einbildung auf das eine oder andere Werkzeug ist völlig fehl am
Platz, wobei eben diese Einbildung bei C-lern deutlicher zu bemerken
ist.
Und wer nur eine Sprache kann, ist sowieso ein armes Würstchen ;D
Yalu schrob:
>...erinnern mich stark an das Basic des Sinclair ZX81 von 1981, das eben->falls genau diese Einschränkungen hatte.
Der ZX81 hatte original nur 1KB RAM. Das ist es aller Ehren wert, was
man damit anstellen konnte.
Wenn BASIC nicht Basic sondern vielleicht "HORST" hieße, hätten nicht so
viele Leute regelrecht Angst davor zuzugeben, daß sie es benutzen.
So aber heißt es: Das ist doch nur Etwas für Anfänger und Lernfaule.
Jemand, der Englischunterricht hatte, kann einen Basic- oder auch einen
Algol- oder Pascalquelltext ohne große Vorkenntnisse lesen, weil die
Schlüsselworte und Befehle oft selbsterklärend sind. Selbst Leute ohne
Kenntnis der englischen Sprache können sich recht schnell hineinfinden.
Zeigt man einem Außenstehenden dagegen einen Quelltext in C, dann reißt
der
ob dieses Kauderwelsches an jedweden verfügbaren Sonderzeichen Mund und
Nase auf und zollt dem "Experten" Respekt vor seinen enormen Kenntnissen
in dieser Art:
"So Etwas Kompliziertes würde ich nie begreifen! Du bist ein Fux (mit
x)
Jemand das DAS beherrscht, muß fürstlich bezahlt werden!"
Nein, es ist nur komplizierter, sich statt Klartext (z.B. Shift left, or
and) Sachen wie <<, ||, && einzuprägen.
Ein falsches Zeichen ruft keinen Sytaxfehler hervor, das Programm macht
nur etwas Anderes als man erwartet. Man sucht sich die Schwindsucht an
den Hals...
MfG Paul
Paul Baumann schrieb:> Zeigt man einem Außenstehenden dagegen einen Quelltext in C, dann reißt> der> ob dieses Kauderwelsches an jedweden verfügbaren Sonderzeichen Mund und> Nase auf und zollt dem "Experten" Respekt vor seinen enormen Kenntnissen> in dieser Art:
Lesen können ist immer ein Vorteil.
Ein C-Quelltext ist keine Literatur. Wenn Du die extrem einfache
und übersichtliche C-Syntax nicht kapierst bleibe bei BASIC.
Beginners All ...
Rico schrieb:> Bibliotheken: Meine jahrelang entstandenen Bibliotheken kann ich alle> schrotten, weil der Einsatz von XMegas erforderlich ist...Danke C.
Wie ich schon mal oben schrieb: "Was hat die Bibliothek mit der Sprache
zu tun?"
Rico schrieb:> Mit Bascom habe ich das nicht einmal gemerkt, außer dass nach 1 Stunde> bereits die I2C-EEprom Funktionen liefen.
Weil jemand anderes fuer dich die Arbeit getan hat. Wenn du eine fertige
Lib fuer den Prozessor hast ist das auch in C in 5 Minuten erledigt. Und
einige neuere Cortex uC haben sowas von Hersteller schon auf dem Chip im
ROM mit drauf. Aufrufen und fertig.
Rico schrieb:> Die, die in den C Bibliotheken das Paradies sehen, haben noch nie mit> einem XMega oder ARM gearbeitet. Wahrscheinlich nur mit Tinys. Die> laufen auch unter C schnell.
Quatsch. ARM/Cortex sind schon dafuer ausgelegt unter C programmiert zu
werden. Von den Herstellern gibt es dazu reichlich Biliotheken als
C-Source b.z.w. in ROM.
C wurde zur Entwicklung von Betriebssystem erschaffen
UNIX,LINUX,WINDOWS,OS9 etc.
Zeig mir ein Betriebssystem das in BASIC programmiert ist.
Rico schrieb:> Ich hab einfach nicht immer Zeit und Lust, mich durch 500 Seiten> Datenblätter zu arbeiten. Das muß eine gute Programmierumgebung für mich> machen. Sonst ist sie für mich nicht zu gebrauchen.
Niemand liest 500 Seiten Datenblatt durch. Man schaut sich kurz das
Kapitel an und dann die Registerbelegung. Ein paar Bits gesetzt und
schon laueft die Funktion. Danach weiss ich auch wie die Hardware an
dieser Stelle funktioniert. Ist wie mit Auto fahren: Kannst du einen
fahren, kannst du alle fahren.
Die Peripherie ist doch bei den meisten uC sehr aenlich.
Paul Baumann schrieb:> Nein, es ist nur komplizierter, sich statt Klartext (z.B. Shift left, or> and) Sachen wie <<, ||, && einzuprägen.
Schreib mal Programme mit 20000+ Zeilen Code. Da bist du fuer jedes
Zeichen das du nicht eintippen must dankbar. Alles andere ist nur
redutantes Geschwaffel.
PeterL schrieb:> Was mir bei solchen Diskussionen immer wieder auffällt ist, dass es eher> die C Programmierer sind, die "draufhauen" und Bascom schlechtreden.
Die draufhauenden C-Leute haben schon so viel Mühe für "ihre"
Programmiersprache aufgewendet und stehen wohl immer noch vor neuen
Überraschungen, daß sie sich nicht vorstellen können, daß es auch
einfacher geht. Die, die C und BASCOM (und mehr) kennen, erkennen
durchaus auch die Vorteile von BASCOM, wie hier im thread zu sehen ist.
Von denen hab ich eigentlich noch nie so unqualifizierte Bemerkungen wie
"Nimm eine vernünftige Programmiersprache" gesehen. C ist wohl in
bestimmten Bereichen der Industriestandard. Warum nicht mit BASCOM
anfangen wenn man die Wahl hat? Jeder Vergleich hinkt aber warum nicht
mit dem 1 X 1 beginnen, vor der Infinitesimalrechnung. Die HW wird einem
schon genug Kopfzerbrachen machen und man wird staunen, wie weit man mit
dem 1 X 1 kommt.
In vielen Forumsbeiträgen scheint durch das viele überhaupt erstmal
Englisch lernen sollten um Programmiersprachen richtig lernen zu können
und der nicht ganz unwichtige Nebeneffekt wäre dann auch noch
Datenblätter verstehen zu können.
PeterL schrieb:> Umgekehrt verneigen sich die meisten demütig, vor der geballten> Intelligenz.
Der Klügere gibt nach und denkt sich seinen Teil
Rico schrieb:> Bibliotheken: Meine jahrelang entstandenen Bibliotheken kann ich alle> schrotten, weil der Einsatz von XMegas erforderlich ist...Danke C.
Das liegt nicht an C, sondern daß Du etwas grundsätzlich falsch gemacht
hast. Wechselt man den CPU-Typ, muß man nur die wenigen Hardwarezugriffe
anpassen.
Das soll aber kein Vorwurf sein, es braucht schon etwas
Programmiererfahrung, um modulare Bibliotheken zu erstellen.
Hilfreich war für mich, daß ich 8051 und AVR in C programmiere. Da
kriegt man quasi einen Blick dafür, wie man die Hardwareunterschiede
kapselt.
Rico schrieb:> Mit Bascom habe ich das nicht einmal gemerkt, außer dass nach 1 Stunde> bereits die I2C-EEprom Funktionen liefen.
Doch so lange?
Ich hatte auch mal meine I2C-Lib vom 8051 auf den AVR angepaßt, dürfte
etwa 10min gedauert haben (SW-I2C).
Der Hauptaufwand war die Anpassung der Portzugriffe, der 8051 hat schon
Open-Drain, der AVR muß das mit dem Directionbit simulieren.
Letzendlich definiert man nur ein paar Macros um (sda_low, sda_high,
sda_in).
Peter
Joachim Drechsel schrob:
>Wenn Du die extrem einfache und übersichtliche C-Syntax nicht kapierst >bleibe
bei BASIC.
Extrem einfach?! Guten Tag, Herr Preil!
;-)
MfG Paul
Paul Baumann schrieb:> Nein, es ist nur komplizierter, sich statt Klartext (z.B. Shift left, or> and) Sachen wie <<, ||, && einzuprägen.
Logisch zu Ende gedacht kommen wir bei COBOL an:
ADD 5 TO A GIVING B
liest sich ja auch gleich viel einfacher als
b = a + 5
(Ernster Hintergrund: Jede domänenspezifische Notation ist ein
trade-off: Einmaliger Lernaufwand gegen kontinuierliche
Aufwandsersparnis in der Anwendung, wenn man es einmal verstanden und
verinnerlicht hat. Für die klassischen Grundrechenarten haben die
meisten von uns das in der Grundschule getan. Andere Sachen lohnen sich
erst, wenn man sie oft genug einsetzt.)
jau schrieb:> PeterL schrieb:>> Was mir bei solchen Diskussionen immer wieder auffällt ist, dass es eher>> die C Programmierer sind, die "draufhauen" und Bascom schlechtreden.>> Die draufhauenden C-Leute haben schon so viel Mühe für "ihre"> Programmiersprache aufgewendet und stehen wohl immer noch vor neuen> Überraschungen, daß sie sich nicht vorstellen können, daß es auch> einfacher geht.
Ihr dreht das Ganze ja wohl zu 180 Grad um.
Was ich hier schon gesehen habe sind immer wieder Threads wo sich Basic
Freaks gegenseitig hochziehen, daß die 'Profis' die C nutzen Basic nur
schlechtmachen wollen weil Basic ja eigentlich besser ist.
Im Endeffekt kommt dann das wohlbekannte heraus was Yalu treffend
zusammengefasst hat. Die eigentlichen Profis nehmen sowiso die Sprache
die für das Problem gerade passt weil sie nämlich beide Sprachen können
und Assembler dazu.
Und wehe wenn man jemandem der Basic anfangen möchte zu C rät, dann wird
man sowas mit Unrat überschüttet.
Also gibt es dann wieder einige, die sich einen Spass daraus machen die
Basic Jünger mit entsprechenden Postings anzufixen, die reagieren dann
ja auch so schön vorhersehbar.
Leute Leute, versucht doch einfach mal euren Horizont zu erweitern.
Ich hatte oben schon mal gefragt:
Mit welcher Programmiersprache ist denn BASCOM geschrieben?
Wenn man das auf beliebiges Basic ausweiten will kann man jetzt fragen:
Welches Betriebssystem wurde mit Basic geschrieben?
Welche Datenbank wurde mit Basic geschrieben??
Und umgedreht:
In was wurde MS Office entwickelt?
In was wurde Open Office entwickelt?
In was wurde Oracle, DB/2, MS SQl Server, Notepad++, Firefox, Java
Compiler, Eclipse, das MS Dev Studio, C#, etc etc etc geschrieben?
Udo Schmitt schrieb:> In was wurde Open Office entwickelt?> In was wurde Oracle, DB/2, MS SQl Server, Notepad++, Firefox, Java> Compiler, Eclipse, das MS Dev Studio, C#, etc etc etc geschrieben?
Interessiert doch im Kontext des Threads überhaupt nicht. Wer seine
Tageseinnahmen zusammenzählen will, tut sich dafür auch nicht unbedingt
'nen HP-35 an. Das ist genau die Mentalität, die man bei C-lern deutlich
bemerken kann - die können nur in ihrem eigenen kleinen Kästchen denken.
Paul Baumann schrieb:> Wenn BASIC nicht Basic sondern vielleicht "HORST" hieße, hätten nicht so> viele Leute regelrecht Angst davor zuzugeben, daß sie es benutzen.
Hab ich nicht. Ich schreibe Programme für WinXP in PureBasic. Vom
einfachen Terminalprogramm bis zu komplexen Bedienoberflächen. Mit
Callbacks. Mit Structures. Mit mehrdimensionalen Arrays. In Farbe und
Bunt.
Ich hab angefangen mit Amiga-Basic. Ich konnte mal Pascal, aber das ist
wohl tot. Ich hatte auch mal GWBasic, grauenvoll. Ich hab mir auch C
angesehen und mich mit einer Mischung aus Mitleid und Entsetzen
abgewandt.
AVRs werden trotzdem in ASM programmiert.
Timm Thaler schrieb:> Ich hab mir auch C> angesehen und mich mit einer Mischung aus Mitleid und Entsetzen> abgewandt.
Das lässt tief blicken, was ist an C denn so schrecklich? Vorallem auf
den ersten Blick? Oberflächlich betrachtet ist doch lediglich der Syntax
etwas anders und weniger geschwätzig im Vergleich zu Basic. Das große
AHA Erlebniss kommt doch bei C erst mit komplexeren Aufgaben.
> AVRs werden trotzdem in ASM programmiert.
Was halt auch keinen Sinn macht. Komplexe Programme werden dadurch
unüberisichtlich, fehleranfällig und null portabel.
gruß cyblord
Hab schon einiges in C gemacht, nicht sehr viel zugegeben, meist in
Basic, weil es meine Anforderungen erfüllt hat, die IDE aus meiner Sicht
recht gut ist und ich mit Basic auf dem 64er damals begonnen habe.
Bascom hat einen wie ich finde gravierenden Vorteil.
Die Zeit bis zum ersten Erfolg ist extrem kurz ... ein "Hallo Welt" oder
LED-blink ist in Sekunden zusammengecoded was Bascom für Einsteiger
durchaus sehr attraktiv macht.
Bis man die C-Umgebung, Make-Files etc. zusammen hat blinkt die LED
unter Bascom schon.
Gerade für Einsteiger ist dies ein wichtiger Faktor, ob man dran bleibt
oder das Gerümpel in die Ecke wirft entschiedet sich u.U. innerhalb von
Minuten.
Wenn die Erfahrung wächst kann der Neuling ja dann in die
Registerzugriffe und ASM einsteigen, geht alles auch unter Bascom. Mit
der Zeit und wachsender Erfahrung wird die Syntax eigentlich
nebensächlich, ob dann C PHP Java-Script oder Bascom für die jeweilige
Problemlösung verwendet wird spielt immer weniger eine Rolle.
Helmut Lenzen schrieb:> Weil jemand anderes fuer dich die Arbeit getan hat. Wenn du eine fertige> Lib fuer den Prozessor hast ist das auch in C in 5 Minuten erledigt.
Das ist das alte Problem von C/C++, auch zum Beispiel gegenueber Java.
Es gibt oft nicht "eine Bibliothek", die man einbinden koennte - sondern
meist entweder keine, oder ein Dutzend von denen sich keine mit den
anderen vertraegt, die man schon hat. Das liegt aber nicht an der
Sprache - eher an einer Mischung aus der historischen Entwicklung und
der Klientel, die diese Sprache benutzt.
Fhutdhb Ufzjjuz schrieb:> Die Zeit bis zum ersten Erfolg ist extrem kurz ... ein "Hallo Welt" oder> LED-blink ist in Sekunden zusammengecoded was Bascom für Einsteiger> durchaus sehr attraktiv macht.
Das geht in C genauso gut.
> Bis man die C-Umgebung, Make-Files etc. zusammen hat blinkt die LED> unter Bascom schon.
Die Installation einer Entwicklungsumgebung gilt aber fuer beide
Sprachen.
AVR-Studio ist genauso einfach zu installieren und Make-Files habe ich
da auch noch nie direkt angefasst.
Fhutdhb Ufzjjuz schrieb:> ob dann C PHP Java-Script oder Bascom für die jeweilige> Problemlösung verwendet wird spielt immer weniger eine Rolle.
Doch die Protabilitaet spielt eine grosse Rolle. Und jetzt nicht wieder
damit kommen das dass immer wieder angefuehrt wird und doch nicht
funktioniert. Ich setze hier zur Zeit AVR,MSP430,ARM/CORTEX ein und da
werden schon Funktionen untereinander ausgetauscht. Man muss halt die
Funktionen so strikt trennen das man Hardware nahe , Hardware
unabhaengige und Applikationsspezifische Teile erhaelt. Dann klappts
auch mit der Protierbarkeit von Funktionen.
Peter hat ja oben ein Beispiel mit seiner I2C Routine gemacht.
Fhutdhb Ufzjjuz schrieb:> Wenn die Erfahrung wächst kann der Neuling ja dann in die> Registerzugriffe und ASM einsteigen, geht alles auch unter Bascom. Mit> der Zeit und wachsender Erfahrung wird die Syntax eigentlich> nebensächlich, ob dann C PHP Java-Script oder Bascom für die jeweilige> Problemlösung verwendet wird spielt immer weniger eine Rolle.
Völlig richtig.
Genau hier sehe ich den großen Unterschied zwischen den Usern hier. Die
angesprochenen Vorteile von Bascom greifen nur wenn man absoluter
Neuling ist. Als erfahrener Entwickler, Informatiker oder sonst was,
kann man mit diesen Argumenten nicht viel anfangen. "Leichter Einstieg"
oder "gute IDE" ziehen dort nicht als Argumente. Und wenn man sowieso
schon 15 Programmiersprachen beherrscht, hat man für Sprüche, wie
kompliziert und böse C doch ist, nur noch ein müdes lächeln übrig.
Darum gehen hier die Meinungen auch so derart auseinander.
PPS: Mein erstes Projekt mit µC war ein Traktometer ... ATMega32 auf
Punktraster, Quarz etc. und LCD dran, an die Kardanwelle nen
Reedkontakt, ins Gehäuse gepappt und die Kiste lief, Programmierung ca.
1h Timer, Impulse zählen LCD-Ausgabe, das machte Lust auf mehr.
Fhutdhb Ufzjjuz schrieb:> PPS: Mein erstes Projekt mit µC war ein Traktometer ... ATMega32 auf> Punktraster, Quarz etc. und LCD dran, an die Kardanwelle nen> Reedkontakt, ins Gehäuse gepappt und die Kiste lief, Programmierung ca.> 1h Timer, Impulse zählen LCD-Ausgabe, das machte Lust auf mehr.
Nunja aber den Hauptteil der Arbeit haben andere für dich erledigt. Was
ja auch ok ist, aber von "hab ich selber gemacht" kann da halt nicht die
Rede sein.
gruß cyblord
Es ist ja nicht so, das ich C nicht lernen will.
Ich habe auch einige Bücher, aber mein Hirn weigert sich standhaft die
Syntax aufzunehmen.
Zwei Kinder, Frau will auch betreut werde, Haus und Garten, bisschen
Sport...da bleibt für C nix übrig :-)
PeterL schrieb:> Ich habe auch einige Bücher, aber mein Hirn weigert sich standhaft die> Syntax aufzunehmen.
Und dabei ist der Syntax einer Sprache eigentlich das kleinste Problem
;-)
Paul Baumann schrieb:> Wenn BASIC nicht Basic sondern vielleicht "HORST" hieße, hätten nicht so> viele Leute regelrecht Angst davor zuzugeben, daß sie es benutzen.
Ich würde BASIC auch dann nicht benutzen, wenn es HORST hieße. Dazu
müsste es mindestens PAUL heißen ;-)
cyblord ---- schrieb:> Fhutdhb Ufzjjuz schrieb:>> PPS: Mein erstes Projekt mit µC war ein Traktometer ... ATMega32 auf>> Punktraster, Quarz etc. und LCD dran, an die Kardanwelle nen>> Reedkontakt, ins Gehäuse gepappt und die Kiste lief, Programmierung ca.>> 1h Timer, Impulse zählen LCD-Ausgabe, das machte Lust auf mehr.>> Nunja aber den Hauptteil der Arbeit haben andere für dich erledigt. Was> ja auch ok ist, aber von "hab ich selber gemacht" kann da halt nicht die> Rede sein.>> gruß cyblord
Spannugsregler, Elkos und µC fertigt ein C-Progger oder ASM-Progger auch
nicht selber ... wo ziehst Du die Grenze?
Die Grenzen ist beim Verständniss. Ein print "Hallo" und dann wird das
auf dem LCD ausgegeben benötigt NULL Verständniss für die Materie. Ich
würde keine lib verwenden, ohne das Gerät selbst mal direkt angesteuert
zu haben. Wenn man es auch ohne lib kann, dann kann man eine lib nehmen
;-)
Das Spannungsregler-Beispiel ist natürlich suboptimal. Aber die
Schaltung eines 7805 kann man auch sehr einfach nachvollziehen und
diskret aufbauen.
Eventuell stehe ich mit meiner Meinung ziemlich alleine da, dass der
eigentliche Reiz immer im Verständniss für die Materie liegt, mit der
man sich beschäftigt.
gruß cylord
Überraschter schrieb:> @ Yalu X. (yalu) (Moderator) schrieb über das goto-Beispiel>>> Autsch! Das ist ja ein geradezu perfektes Paradebeispiel dafür, wie man>> Gotos nicht benutzen sollte.>> Herrlicher Beitrag! Applaus!>> ;)
Ah kenne jetzt Bascom nicht so aber selbst bei GW/qBasic waren Gotos
schon meist unsinnig dafür gibt es Call.
cyblord ---- schrieb:> Eventuell stehe ich mit meiner Meinung ziemlich alleine da, dass der> eigentliche Reiz immer im Verständniss für die Materie liegt, mit der> man sich beschäftigt.
Meinst du nicht, da bleibt noch genug "Materie", auch wenn man Programme
in BASCOM schreibt?
was? schrieb:> cyblord ---- schrieb:>> Eventuell stehe ich mit meiner Meinung ziemlich alleine da, dass der>> eigentliche Reiz immer im Verständniss für die Materie liegt, mit der>> man sich beschäftigt.>> Meinst du nicht, da bleibt noch genug "Materie", auch wenn man Programme> in BASCOM schreibt?
Zumindest nicht auf der SW-Ebene.
cyblord ---- schrieb:> Die Grenzen ist beim Verständniss. Ein print "Hallo" und dann wird das> auf dem LCD ausgegeben benötigt NULL Verständniss für die Materie. Ich> würde keine lib verwenden, ohne das Gerät selbst mal direkt angesteuert> zu haben.
Das würde aber im Umkehrschluss bedeuten, daß du kein PC benutzen kannst
bevor du nicht für alle Peripherie einen Systemtreiber geschrieben hast.
Ausserdem dürftest du keine Funktionen der C Library nutzen.
Ich stimme allerdings mit dir überein, daß programmieren mehr ist als
sich ein paar Code Fragmente aus dem Internet zusammenzukopieren und
sich diese dann in einem Forum zum funktionieren bringen zu lassen. Das
wurde hier je schon oft genug versucht/gemacht.
Da ich nicht weiss wie Fhutdhb Ufzjjuzs Projekt ausgesehen hat ist dies
jetzt KEINE Anspielung auf sein Traktometer, sondern allgemein gemeint.
cyblord ---- schrieb:> Eventuell stehe ich mit meiner Meinung ziemlich alleine da, dass der> eigentliche Reiz immer im Verständniss für die Materie liegt, mit der> man sich beschäftigt.
Eigentlich nicht, ich sehe das genauso.
Bei den meisten Bascom Threads hier im Forum geht es doch um Probleme
die der TO deshalb nicht verstanden hat weil er sich mit der Materie
nicht auseinander gesetzt hat sondern nur die fertige Loesung genommen
hat. Tritt dabei ein kleines Problemchen auf stehen die meistens auf dem
Schlauch.
cyblord ---- schrieb:>> Meinst du nicht, da bleibt noch genug "Materie", auch wenn man Programme>> in BASCOM schreibt?>> Zumindest nicht auf der SW-Ebene.
Damit stellst du jede Bibliothek und jedes Framework in Frage. Warum
denn dann nicht gleich in Assembler?
Udo Schmitt schrieb:> Das würde aber im Umkehrschluss bedeuten, daß du kein PC benutzen kannst
Nunja, diese Entgegnung habe ich kommen sehen ;-)
Es gibt immer ein Abstraktionslevel hinter das wir nicht sehen können.
Beim PC ist dies im täglichen Umgang sehr hoch angesiedelt.
> bevor du nicht für alle Peripherie einen Systemtreiber geschrieben hast.
Nein, aber wenn man keine Ahnung hat, was ein Treiber ist, und wie er
grundsätzlich funktioniert und wie er mit dem System interagiert, dann
wird eine ernsthafte Entwicklung für den PC auch schnell ihre Grenzen
finden. Darum geht es.
> Ausserdem dürftest du keine Funktionen der C Library nutzen.
Habe früher viele Standard-Funktionen nachgebaut, teils auch aus
Unkenntniss darüber dass es dafür fertige Funktionen gab. Sowohl beim PC
als auch beim µC mit AVR-GCC.
> Damit stellst du jede Bibliothek und jedes Framework in Frage. Warum> denn dann nicht gleich in Assembler?
Denkst du, Frameworks und Bibs gibt es, weil der Entwickler es ohne
nicht könnte? Die Gründe sind doch ganz andere. Aber bei BASCOM und
Arduino wird Unfähigkeit durch libs kaschiert. Und das ist das Problem.
@Helmut:
Ja bei BASCOM und auch bei Arduino Benutzern ist dieses Problem weit
verbreitet. Fertige Libs für alles, der Rest per copy&paste und dann
fliegt einem alles um die Ohren wenn eine Komma falsch gesetzt ist.
gruß cyblord
Helmut Lenzen schrieb:> Bei den meisten Bascom Threads hier im Forum geht es doch um Probleme> die der TO deshalb nicht verstanden hat weil er sich mit der Materie> nicht auseinander gesetzt hat sondern nur die fertige Loesung genommen> hat.
Das ist aber nicht Bascom-spezifisch, das sieht man C genauso oft,
vielleich sogar noch öfter. Es gibt in diesem Forum mehr als genug
Threads, in denen der Fragende nicht nur die Hardware nicht versteht,
sondern auch die verwendete Programmiersprache.
Da meine AVRs weder C noch Basic können, programmiere ich sie in
Assembler. Das ist dann wenigstens wirklich selbst gemacht. Oder
vielleicht doch nicht? Denn irgendwer hat ja den Befehssatz definiert,
die Innereien kreiert und den Assembler geschrieben... Scheiß Spiel, man
bekommt wirklich nix mehr selbst gebacken...
...
Mir ist es völlig wurscht, welche Programmiersprache "die Beste" ist.
Das Problem an Bascom ist nicht die Programmiersprache, sondern die
Einstellung einiger Benutzer, dass sie von der Programmiersprache
erwarten, dass diese ihr Problem (das der "Programmierer") alleine
erkennt und löst. Und wenn sie das nicht tut, dann sind alle anderem im
Forum doof, weil die "Programmierer" ihre Frage nicht mal so formulieren
können, dass andere Menschen sie verstehen. Noch schlimmer ist es, wenn
man denjenigen die Lösung nicht gleich auf einem silbernen Tablett
serviert.
Basic ist toll als Einstieg. Damit habe ich auch auf einem Apple ][
angefangen und dann lange Zeit benutzt. Damals war mir Assembler zu
kompliziert.
In der Schule kam dann noch Pascal dazu. Irgendwann dachte ich, ich
müsste C++ lernen - da muss man sich um zu viel selber kümmern. Deswegen
bin ich bei der PC-Programmierung wieder bei VisualBasic gelandet und
dann den Weg zum C#.NET, weil man damit schnell zu einem Ergebnis kommt,
ohne sich groß um irgendwelche Konstruktoren und Destruktoren kümmern zu
müssen.
Das ist was für Leute, die richtig programmieren, nicht das, was ein
(Nichtinformatik-) Ingenieur oder Hobby-Anwender braucht (meine
subjektive Meinung).
cyblord ---- schrieb:> Eventuell stehe ich mit meiner Meinung ziemlich alleine da, dass der> eigentliche Reiz immer im Verständniss für die Materie liegt, mit der> man sich beschäftigt.
Stehst du nicht.
Helmut Lenzen schrieb:> Bei den meisten Bascom Threads
Fairerweise muß man aber sagen, daß das bei mindestens genauso vielen
"C-Threads" auch so ist.
Udo Schmitt schrieb:> Das würde aber im Umkehrschluss bedeuten, daß du kein PC benutzen kannst> bevor du nicht für alle Peripherie einen Systemtreiber geschrieben hast.
Ach komm. Dann müsste man auch die Makromoleküle, aus denen sich der
Kunststoff der Tastatur zusammensetzt, kennen und mindestens einmal
selbst zusammengemischt haben. Genauso hat man den Baum, aus dem der
Stuhl gemacht wurde, auf dem man sitzt, natürlich selbst gefällt.
mfg.
cyblord ---- schrieb:> Die Grenzen ist beim Verständniss. Ein print "Hallo" und dann wird das> auf dem LCD ausgegeben benötigt NULL Verständniss für die Materie. Ich> würde keine lib verwenden, ohne das Gerät selbst mal direkt angesteuert> zu haben. Wenn man es auch ohne lib kann, dann kann man eine lib nehmen> ;-)> Eventuell stehe ich mit meiner Meinung ziemlich alleine da, dass der> eigentliche Reiz immer im Verständniss für die Materie liegt, mit der> man sich beschäftigt.>> gruß cylord
Nein, stehst Du nicht, ich gebe dir absolut Recht, heute verwende ich
kaum mehr Bascom Highlevelbefehle, beim Traktometer damals schon und es
führte zu einem scchnellen Ergebnis was für mich dann Motivation war am
Ball zu bleiben.
Beispiel GLCD ... da hat Bascom ne schöne Lib dafür ... dumm wirds aber
wenn man vom Routing her die Ansteuerung nicht so machen kann wie das in
Bascom eben vorgegeben wird. Da muss man dann seinen eigenen "Treiber"
schreiben, genauso wie in C ... idealerweise baut man sich auch nen
header File mit den Deklarationen und die Subroutinen in eine separate
Datei, damit man die in anderen Projekten wiederverwenden kann ... wird
dann einfach per include eingefügt und gut ist.
Man muss die Highlevelbefehle nicht gezwungenermaßen verwenden,
genausowenig wie in C die Libs ... liest man ja auch oft genug hier im
Forum "Problem mit Lib von x für Aufgabe y"
pegel schrieb:> In welcher Sprache ist eigentlich Bascom selbst geschrieben ? :-)
Bascom kann nur mit Bascom geschrieben worden sein. Das ist wie mit
Chuck Norris. Er kann sich nur selbst gezeugt haben.
FAZIT dieses Threads:
Bascom ist ein geeignetes Toy für Hobbyfummler, die ohne große
Kenntnisse oder Lernaufwand mal schnell was zusammenstöpseln wollen,
ohne sich für Details zu interessieren, und die nicht in der Lage sind,
sei es aus mentalen oder zeitlichen Gründen, sich mit professionellen
Tools auseinanderzusetzen.
Also keine neuen Erkenntnisse, und alles im Lot.
Bizarr wird's nur, wenn genau DIESE Leute dann jammern, daß ihnen jemand
aus Osteuropa/Indien/China den Job wegnimmt. Mir kann nämlich keiner
erzählen, er verhielte sich im Hobby grundlegend anders als im Job.
Tröte schrieb:> FAZIT dieses Threads:>> Bascom ist ein geeignetes Toy für Hobbyfummler, die ohne große> Kenntnisse oder Lernaufwand mal schnell was zusammenstöpseln wollen,> ohne sich für Details zu interessieren, und die nicht in der Lage sind,> sei es aus mentalen oder zeitlichen Gründen, sich mit professionellen> Tools auseinanderzusetzen.>> Also keine neuen Erkenntnisse, und alles im Lot.>> Bizarr wird's nur, wenn genau DIESE Leute dann jammern, daß ihnen jemand> aus Osteuropa/Indien/China den Job wegnimmt. Mir kann nämlich keiner> erzählen, er verhielte sich im Hobby grundlegend anders als im Job.
So polemisch die Zusammenfassung ist, so möchte ich antworten:
C ist für manche das, was dem HiFi Freak seine esotherisch behandelten
Kabel sind.
jau schrieb:> C ist für manche das, was dem HiFi Freak seine esotherisch behandelten> Kabel sind.
Falsch, C ist eher das Kupfer in der Leitung. Was man damit macht: 0,30
Euro pro Meter normale Leitung oder 1000 Euro pro Meter für
linksdrehende elektronenfreie Ultra Hip Kabel ist dann Sache desjenigen
der das Kupfer benutzt.
Und Basic ist dann halt ne Aluleitung, vieleicht mehr Innenwiderstand
aber leitet auch und ist in bestimmten Bereichen einsetzbar.
Und wer die 1000 Euro Leitung kauft ist der Trottel der zu wenig Wissen
hat, egal ob von C von Basic oder von Stromleitung.
Wissen ist nur durch mehr Wissen zu ersetzen.
> Bibliotheken: Meine jahrelang entstandenen Bibliotheken kann ich> alle schrotten, weil der Einsatz von XMegas erforderlich ist...Danke C.
Schwaches Argument.
Der BASCOM Hersteller hat dir die Umsetzung auf XMega abgenommen.
Irgendwer muss sie schliesslich machen, das passiert auch bei BASCOM
nicht von alleine.
Und wenn du deine Bibliotheken so aufgebaut hast, dass du davon wirklich
nichts mehr wiederverwenden kannst, noch nicht einmal die API, dann hast
du deine Bibliotheken schlecht aufgebaut.
In beiden Fällen kann da aber die Sprache C bzw. die Sprache BASCOM nix
dafür.
Udo Schmitt schrieb:> Und wer die 1000 Euro Leitung kauft, ist der Trottel, der zu wenig Wissen> hat - egal, ob von C, von Basic oder von Stromleitungen.lol und sowas von wahr!
Tröte schrieb:> FAZIT dieses Threads:>> Bascom ist ein geeignetes Toy für Hobbyfummler, die ohne große> Kenntnisse oder Lernaufwand mal schnell was zusammenstöpseln wollen,> ohne sich für Details zu interessieren, und die nicht in der Lage sind,> sei es aus mentalen oder zeitlichen Gründen, sich mit professionellen> Tools auseinanderzusetzen.>> Also keine neuen Erkenntnisse, und alles im Lot.>> Bizarr wird's nur, wenn genau DIESE Leute dann jammern, daß ihnen jemand> aus Osteuropa/Indien/China den Job wegnimmt. Mir kann nämlich keiner> erzählen, er verhielte sich im Hobby grundlegend anders als im Job.
Du hattest woh Polemikclown zu Mittag oder was ...
nein, das Fazit ist: "Jedem Narren seine Kappe"
Was die verlagerung meines Jobs nach China angeht ... eher nicht. 18ha
Weinberge lassen sich nicht so einfach verschieben.
Und was die Güte der Produkte mit Bascomprogrammierung angeht ...
Mich hat Bascom zum shake hands mit der Kanzlerin gebracht inklusive
Gratulation (Bildanhang, die neben mir ist die Kanzlerin) zum
innovativen Produkt ... und Dich?
pegel schrieb:> In welcher Sprache ist eigentlich Bascom selbst geschrieben ? :-)
in Bascom ??
Auf jeden Fall ist Arduino noch viel besser als Bascom, wenn man als
Messlatte die Argumente hier für Bascom nimmt.
Fhutdhb Ufzjjuz schrieb:> Mich hat Bascom zum shake hands mit der Kanzlerin gebracht inklusive> Gratulation
Sorry aber da liegt mir auf der Zunge:
"Da sieht man wieder daß Politiker keine Ahnung von Technik haben"
Oder
"Tja, die is halt Physiker, die haben keine Ahnung von
Softwareentwicklung"
Nein im Ernst, Gratulation (zum Preis, nicht zum Shakehands mit dem
weiblichen Klon vom Pfälzer Saumagen)
Fhutdhb Ufzjjuz schrieb:> shake hands mit der Kanzlerin
Sagtest Du mir, die Firmware der Kanzlerin sei in Bascom geschrieben,
glaubte ich Dir sofort ... funktioniert irgendwie und auch schon recht
lange, aber state-of-the-art ist doch deutlich anders ;-)
Es ist einfach Blödsinn Hobby und Beruf durcheinander zu schmeißen, es
gibt da einfach zu verschiedene Anforderungen!
Wenn es einem im Hobby Spaß macht uC in BASIC zu programmieren, warum
nicht! Wenn es fertige Bibliotheken gibt, könnte ich mir zur schnellen
Testprogrammerstellung BASIC eventuell auch im Beruf vorstellen.
Ich habe keine Angst BASIC einzusetzen. Schaut mal hier:
http://www.adwin.de/
Das Teil wird in einem BASIC Dialekt programmiert, der so erweitert
wurde, daß er für die Echtzeitprogrammierung taugt.
Aber für die uC Programmierung ist BASIC absolut nicht die erste Wahl.
In Form von BASCOM steht es nur für die AVR's zur Verfügung. Im
professionellen Umfeld muß die Portierbarkeit gegeben sein. Da oft die
Forderung nach Second source Bauteilen besteht, um eben mit
abgekündigten uC's klarzukommen. Oder in unterschiedlichen Produkten
kommen unterschiedliche uC's zum Einsatz. Da hilft dann die
Portierbarkeit Zeit und damit Kosten zu sparen, indem ich C Routinen auf
unterschiedlichen uC's wiederverwende. Bei richtiger Softwarearchitektur
brauchen nur die hardwarenahen Teile angepasst werden. Der Rest kann 1:1
übernommen werden.
Denn der entscheidende Unterschied zwischen BASIC und C ist, daß es eine
Unmenge an BASIC Dialekten gibt, aber C dagegen ist eine genormte
Programmiersprache! Deshalb existiert für die meisten (wenn nicht alle)
uC's ein C-Compiler.
Außerdem gibt es für C solche Tools wie PC-Lint, Doxygen oder
irgendwelche Unit Testframeworks. Inwieweit würde das für z.B. BASCOM
zur Verfügung stehen? Der Einsatz dieser oder ähnlicher Tools ist aber
im Hobbybereich auch völlig uninteressant. Wohingegen man im
professionellen Umfeld so gut wie nicht mehr um solche Tools herumkommt.
Also laßt die Kirche im Dorf, und benutzt das jeweilige Werkzeug, für
die jeweils passende Aufgabe! Und akzeptiert auch mal, daß es Menschen
gibt, die Eure Meinung nicht teilen! Warum muß eine Diskussion hier
immer persönlich werden! Das nützt niemanden!
Tröte schrieb:> Sagtest Du mir, die Firmware der Kanzlerin sei in Bascom geschrieben,> glaubte ich Dir sofort ... funktioniert irgendwie und auch schon recht> lange, aber state-of-the-art ist doch deutlich anders ;-)
Die Software der Kanzlerin sieht so aus:
while(1)
{
}
Helmut Lenzen schrieb:>> Die Software der Kanzlerin sieht so aus:>> while(1)> {> }
Ahhh das schmerzt in den Augen. So geht das nicht! Zeichenverschwendung
(ja auch Whitespaces sind vollwertige Zeichen und sollten respektiert
werden).
So ists besser:
while(1);
Helmut Lenzen schrieb:> Geht noch kuerzer:>> for(;;);
Finde ich aber ideologisch bedenklich. Denn for impliziert eine Schleife
mit einer maximalen Anzahl von Durchläufen. Also genau das Gegenteil
einer Endlosschleife. Meist ist es ein Programmierfehler wenn eine
for-Schleife zur Endlosschleife wird.
Allerdings würde mich interessieren ob das Konstrukt in Bascom möglich
ist. In alten Basics mussten for-Schleifen irgendwann enden. So gesehen
hält sich Basic daher eigentlich strikter an die theoretische Grundlage
von for, nämlich der Klasse der LOOP Äquivalenten Sprachen. In Basic
wäre daher ein Programm mit for-Schleifen nicht Turing-Vollständig, was
auch korrekt wäre nach der Theorie.
gruß cyblord
cyblord ---- schrieb:> Meist ist es ein Programmierfehler wenn eine> for-Schleife zur Endlosschleife wird.
Meist ist es ein Programmierfehler wenn eine while-Schleife zur
Endlosschleife wird. Es macht keinen Unterschied.
>> for(;;);> Finde ich aber ideologisch bedenklich.
Nö. Das ist das Standardidiom für eine Endlosschleife in C und C++.
Einige Compiler haben bei hohen Warninglevels auch die Eigenschaft, dass
bei
while (1) { /*...*/ }
irgendeine Warnung im Stil von "condition is always true" rausgehauen
wird. Mit for(;;) kriegt man die dann weg - es ist keine Condition mehr
da, der Compiler ist zufrieden.
Dr. Dr. med Foo schrieb:> cyblord ---- schrieb:>> Meist ist es ein Programmierfehler wenn eine>> for-Schleife zur Endlosschleife wird.>> Meist ist es ein Programmierfehler wenn eine while-Schleife zur> Endlosschleife wird. Es macht keinen Unterschied.
Hmm, bei µC Programmierung sieht man aber regelmäßig Endlosschleifen.
Schlagt doch dem Standards Committee eine Spracherweiterung vor:
for ever { }
cyblord ---- schrieb:> In alten Basics mussten for-Schleifen irgendwann enden.
Ich weiß nicht, wie alt das BASIC ist, von dem Du sprichst, aber im
Microsoft-basierten C-64-BASIC hat z.B.
Udo Schmitt schrieb:> Schlagt doch dem Standards Committee eine Spracherweiterung vor:> for ever { }> Die Negation ist dann "for never () {}" ?
Dafür!
/sign
Joachim Drechsel schrieb:> Die Negation ist dann "for never () {}" ?
:-)
Dafür gibts dann die Fehlermeldung: "unreachable code". Zumindest wenn
innerhalb der geschweiften Klammer was steht.
Ist wie bei der Digitaltechnik, wenn es da nach Strom riecht weisst du
vorher auch nicht ob jetzt ein "immer" oder ein "nimmer" gatter
entstanden ist.
cyblord ---- schrieb:> Allerdings würde mich interessieren ob das Konstrukt in Bascom möglich> ist. In alten Basics mussten for-Schleifen irgendwann enden.
Bascom hat (wie VB) die Anweisung Exit. Damit kann man aus Schleifen,
Subs und Funktionen herausspringen, ohne den Stack zu beschädigen.
Warum hackst Du eigentlich immer auf etwas (Bascom) herum, was Du gar
nicht kennst??
...
Yalu schrob:
>Ich würde BASIC auch dann nicht benutzen, wenn es HORST hieße. Dazu>müsste es mindestens PAUL heißen ;-)
Ja, das wäre was! ;-)
Aber ich glaube nicht, daß ich es schaffe, eine eigene
Programmiersprache
"herzustellen".
Es ist mir leider auch nicht gelungen, herauszufinden, womit Bascom
selbst erstellt wurde. Das ist eine interessante Frage.
Hier ist ein Link auf die Herstellerseite von Bascom, auf der einige von
Nutzern erstellte Programme zu finden sind. Man sieht, daß es da nicht
nur um das Blinkenlassen einer LED geht...
http://www.mcselec.com/index.php?option=com_content&task=category§ionid=7&id=79&Itemid=57
@Weinbauer
ich gratuliere Dir zu dem errungenen Preis, wobei es wahrscheinlich
anstrengender ist, in einem Weinberg ein Array von Weinstöcken anzulegen
und dessen Inhalt im Herbst einzeln einzulesen als ein Glas Wein mit der
Kanzlerin zu heben...
MfG Paul
Hannes Lux schrieb:> cyblord ---- schrieb:>> Allerdings würde mich interessieren ob das Konstrukt in Bascom möglich>> ist. In alten Basics mussten for-Schleifen irgendwann enden.>> Bascom hat (wie VB) die Anweisung Exit. Damit kann man aus Schleifen,> Subs und Funktionen herausspringen, ohne den Stack zu beschädigen.
Klaro, gibts fast überall. Hat aber mit meinem Zitat nichts zu tun.
> Warum hackst Du eigentlich immer auf etwas (Bascom) herum, was Du gar> nicht kennst??
Das war keine Kritik an BASCOM. Allerdings habe ich hinreichend viel
Erfahrung mit allen möglichen BASICs. Aber es stimmt schon, selbst bei
Apple Basic auf dem \\c konnte man ein STEP definieren und so
endlosschleifen erzeugen:
for i=1 to 5 step -1
gruß cyblord
Paul Baumann schrieb:> ich gratuliere Dir zu dem errungenen Preis, wobei es wahrscheinlich> anstrengender ist, in einem Weinberg ein Array von Weinstöcken anzulegen
Besonders mit mehr als 2 Dimensionen :=)
Paul Baumann schrieb:> Es ist mir leider auch nicht gelungen, herauszufinden, womit Bascom> selbst erstellt wurde. Das ist eine interessante Frage.
Koennte man eventuell am Disassemblierten EXE File erkennen.
Helmut Lenzen schrieb:> Paul Baumann schrieb:>> Es ist mir leider auch nicht gelungen, herauszufinden, womit Bascom>> selbst erstellt wurde. Das ist eine interessante Frage.>> Koennte man eventuell am Disassemblierten EXE File erkennen.
Ich würde da einfach mal auf MS Visual Studio, genauer Visual C++
tippen.
Udo Schmitt schrieb:> Fhutdhb Ufzjjuz schrieb:>> Mich hat Bascom zum shake hands mit der Kanzlerin gebracht inklusive>> Gratulation>> Sorry aber da liegt mir auf der Zunge:> "Da sieht man wieder daß Politiker keine Ahnung von Technik haben"> Oder> "Tja, die is halt Physiker, die haben keine Ahnung von> Softwareentwicklung">> Nein im Ernst, Gratulation (zum Preis, nicht zum Shakehands mit dem> weiblichen Klon vom Pfälzer Saumagen)
Nee, die Entscheidung traf ein Gremium von Leuten aus der Branche, die
Dame war lediglich zur Verleihung präsent. War aber dennoch eine
interessante Erfahrung, zum Einen der Ablauf, viele Herren im schwarzen
Anzug, die förmlich BKA auf der Stirn tätowiert hatten, zum Anderen, das
der Preis für Verfahrens- und Prozesstechnik an mich als Onemanshow ging
und so manche Größe in der Branche leer ausging.
Merci :o)
Wär aber auch egal gewesen ob das Ding nun in Bascom, C, Java oder
Fortran programmiert gewesen wäre ... hat kein Aas danach gefragt, die
Funktion musste gegeben sein, was beim Wettbewerb von der Hardware her
nicht der Fall war.
Fhutdhb Ufzjjuz schrieb:> Wär aber auch egal gewesen ob das Ding nun in Bascom, C, Java oder> Fortran programmiert gewesen wäre ... hat kein Aas danach gefragt, die> Funktion musste gegeben sein, was beim Wettbewerb von der Hardware her> nicht der Fall war.
Jepp, im Endeffekt zählt halt was hinten rauskommt :-)
Schönes Wochenende
ich mag BASCOM.
Manchmal brauche ich etwas Zeit um einen Umweg für unerklärliche Effekte
zu bauen.
Also ich finde einen Weg, kann aber nicht erklären warum es nicht so wie
beschrieben funktioniert.
C ist dann für mich eher wie diese Krähe die durch mein Tintenfass
lief...
und dann kreuz und quer über meinen Schreibblock.
Kopfschüttel.
Was habt ihr immer mit den C-Sonderzeichen. Soviele sinds doch gar nicht
bzw. sind doch ohnehin immer dieselben 10 (größenordnungsmässig).
Programmiert doch mal in APL. Da könnt ihr euch über Sonderzeichen
beschweren. Wenn da mal ein normales ASCII Zeichen auftaucht, ist das
schon die Ausnahme, für die man eigentlich sofort ein Grillfest
anzetteln sollte um das Ereignis zu feiern.
Eine Programmiersprache ist ein WERKZEUG mit dem man seine Arbeit macht.
Mehr nicht. Beim Programmieren gehts doch nicht darum, ob ich jetzt
if then
endif
oder
if( ) {
}
schreibe. Das sind doch nur 2 verschiedene Schreibweisen. Der
interessante Teil beim Programmieren sind die Verfahren, die
Algorithmen. Dort steckt das Gehirnschmalz drinnen und nicht ob ich
jetzt DO LOOP oder while(1) schreiben muss.
Helmut Lenzen schrieb:> Die Software der Kanzlerin sieht so aus:> while(1)> {> }
Und beim Koalitionspartner:
while(0);
In einigen Landesparlamenten hat der Compiler das auch schon
wegoptimiert.
Also das ist jetzt nicht politisch gemeint.
Deshalb nochmal eine ernsthafte Frage:
Kann Bascom auch in verschiedenen Levels optimieren?
mfg.
Paul Baumann schrieb:> Aber ich glaube nicht, daß ich es schaffe, eine eigene> Programmiersprache> "herzustellen".
Eine Sprache in der das Programm als Gedicht geschrieben werden muss,
DAS wär doch mal was.
Zum eigentlichen Thema sag ich lieber nix, Pulverfass...
cyblord ---- schrieb:>> AVRs werden trotzdem in ASM programmiert.> Was halt auch keinen Sinn macht. Komplexe Programme werden dadurch> unüberisichtlich, fehleranfällig und null portabel.
Programme werden dadurch schnell und ressourcenschonend.
Übersichtlichkeit erreicht man durch Strukturierung, Fehleranfälligkeit
minimiert man durch saubere Programmierung, Portierbarkeit zumindest auf
weiterentwickelte AVRs erreicht man durch Einsatz von Konstanten statt
direkter Adressierung. Also genau so wie bei "höheren"
Programmiersprachen.
Dafür weiss ich in ASM genau, was der AVR im Programm macht.
Ich hab mir einfach mal eine Aufgabe in einer "höheren" Sprache
geschrieben und das Ergebnis mit der Lösung in ASM verglichen. Wenn dann
für einfache verkettete Rechenoperationen ständig Werte "gestort" und
"geloadet" werden und die Ausführung in einer doch etwas zeitkritischen
PID-Regelung dafür fünfmal solange dauert, weiss ich was ich an ASM
habe.
Timm Thaler schrieb:> weiss ich was ich an ASM habe.
Du bist hier im falschen Thread.
Hier läuft:
"Ewig-gestrige C-Freaks" vs "Weitsichtige Bascom-Programmierer"
Assembler-Friemler werden woanders fertig gemacht.
mfg.
Ich habe früher auch viel BASIC programmiert.
Erst aufm Sinclair ZX81, dann aufm Casio Taschenrechner, dann QBasic,
Quickbasic und schließlich FreeBasic. Ich schäme mich so! Ich glaub ich
brauch nächste Woche wieder ne Sitzung beim Therapeuten.
Beruflich progge ich nicht mehr, haben wir alles in die Gegend den
Punjab aussgegliedert. Ist billiger, sagt unser Prozessoptimierer.
Marek N. schrieb:> Ich schäme mich so! Ich glaub ich> brauch nächste Woche wieder ne Sitzung beim Therapeuten.
Musst du nicht.
Hier sind die Bascomiker die Guten und die C-Programmierer die Deppen.
mfg.
Paul Baumann (Gast) schrieb:
> Wenn BASIC nicht Basic sondern vielleicht "HORST" hieße, hätten nicht so> viele Leute regelrecht Angst davor zuzugeben, daß sie es benutzen.
Dann gäbe es auch das wunderbare Namenskonstrukt
Turbohorst 1.0
Ein mögliches Derivat hieße dann
Blitzhorst
Einen Horst-Compiler gäbs vermutlich ebenfalls
und für Windows gäbe es ein
Visual Horst
;-)
Schon 182 Posts hier
wird Zeit dass jemand Gott oder Hitler ins Spiel bringt ;)
Echte Kerle programmieren übrigens in BF
http://de.wikipedia.org/wiki/Brainf*ck
(Link bitte selbst editieren)
snowfly schrieb:> Echte Kerle programmieren übrigens in BF> http://de.wikipedia.org/wiki/Brainf*ck> (Link bitte selbst editieren)
lol, damit habe ich wirklich heute(gestern) mittag noch programmiert :D
Bin da über einen anderen Zusammenhang drauf gekommen.
Im Gegensatz zur weit verbreiteten Annahme ist es übrigens nicht Zweck
der Sprache, möglichst kompliziert zu sein. Das ist Malbolge oder so
ähnlich.
snowfly (Gast) schrieb:
> Schon 182 Posts hier> wird Zeit dass jemand Gott oder Hitler ins Spiel bringt ;)
Ooeech habe doch annngeorrrrdnet, dass noecht mehr compilirrrrrrrrt,
sondoerrn nurrrr noch überrrrrrrsoetzt wirrrd, in meinoem Rrrrrreich.
:-)
Nicht Waffen töten Menschen, sondern Menschen töten Menschen. So ist's
auch mit der Programmiersprache. Nicht BASIC ist Schuld, wenn das
Projekt nach schneller Anfangsentwicklung stagniert, sondern der
Entwickler, der durch diese schnellen Anfangserfolge den Auftraggeber zu
einem Basic-Projekt überredet und den Aufwand eines echten Projektes
unterschätzt hat. Zum richtigen Einschätzen des Aufwands eines echten
Projekts gehört eine gewisse Portion Erfahrung, und wer die hat, kennt
genügend Programmiersprachen, Betriebssysteme und Umgebungen, dass seine
Wahl nur in wenigen speziellen Fällen aus eher seltenen Gründen auf
BASIC fallen wird.
Nur deswegen wird mit BASIC so viel Schindluder getrieben, weil es halt
so oft die erste Sprache ist, und Anfänger entsprechend oft ihr Lehrgeld
in der Währung BASIC bezahlen.
Immer wieder zu beobachten ist das viele meinen nur weil sie eine
bestimmte Sprache können wären sie gleich Profis.
Programmieren hat doch zu aller erst mit den Algorithmen zu tun, die
Sprache ist erst mal zweitrangig.
Und wenn es keine Lib, Highlevelbefehl etc pp gibt, dann sollte man eben
noch wissen wie man sich das Bastelt.
Natürlich muß man Anforderungen wie Portierbarkeit in die Auswahl bei
bedarf mit reinnehmen, aber ich denke man sollte immer Idiologiefrei
beim Projektstart vorgehen.
Wahnsinn, der ganze Beitrag ohne Nennung einer Sprache. :-)
Übrigens ist es auch im richtigen Leben von Vorteil wenn man mehr als
eine Sprache kann.
Paul Baumann schrieb:>>Ich würde BASIC auch dann nicht benutzen, wenn es HORST hieße. Dazu>>müsste es mindestens PAUL heißen ;-)>> Ja, das wäre was! ;-)> Aber ich glaube nicht, daß ich es schaffe, eine eigene> Programmiersprache> "herzustellen".
Blaise PASCAL hat keine eigene Programmiersprache entwickelt.
ADA Lovelace hat keine eigene Programmiersprache entwickelt.
Monty PYTHON haben keine eigene Programmiersprache entwickelt.
HASKELL Curry hat keine eigene Programmiersprache entwickelt.
Gustave EIFFEL hat keine eigene Programmiersprache entwickelt.
PAUL Baumann wird auch keine eigene Programmiersprache entwickeln,
... aber vielleicht findet sich jemand in seiner ständig wachsenden
Fangemeinde, der PAUL für ihn auf den Weg bringt.
Bitte füllen Sie dieses Feld aus. schrieb:> Eine Sprache in der das Programm als Gedicht geschrieben werden muss,> DAS wär doch mal was.
An so etwas hätte ich auch als erstes gedacht. Ein Ansatz, in welche
Richtung PAUL (Akronym für "Programming Artistically Using Lyricism")
gehen könnte, ist Shakespeare:
http://shakespearelang.sourceforge.net/report/shakespeare/Das ist doch eine schöne Programmiersprache, die besonders die Hasser
kryptischer C-Operatoren zum Schwärmen bringen dürfte. Man schaue sich
nur die Beispielprogramme auf der Webseite an. Kann da Basic auch nur im
Ansatz mithalten?
Paul ist aber nicht Shakespeare und sein Stil ist auch ein anderer.
Deswegen muss PAUL von Grund auf neu entwickelt werden, was — um dem
großen Namen halbwegs gerecht zu werden — sicher einige Jahrzehnte in
Anspruch nehmen wird. Mal sehen, ob ich mal etwas Zeit übrig habe ...
Paul Baumann schrieb:> Es ist mir leider auch nicht gelungen, herauszufinden, womit Bascom> selbst erstellt wurde. Das ist eine interessante Frage.
Sowohl der Compiler als auch die IDE scheinen in Delphi geschrieben zu
sein.
Guter Brauch ist es ja eigentlich, einen Compiler in seiner eigenen
Sprache zu schreiben, also einen C-Compiler in C, einen Lisp-Compiler in
Lisp usw., so dass er sich selbst übersetzen kann. Das hat neben
technischen und organisatorischen Vorteilen auch einen interessanten
philosophischen Aspekt: Er ist die Existenzberechtigung seiner selbst.
Aber ok, bei einem Cross-Compiler liegen die Dinge etwas anders. Wäre
der Autor aber ein echter Basic-Freak, hätte er Bascom wenigstens in
Visual Basic oder dergleichen geschrieben ;-)
Yalu X. schrieb:> philosophischen Aspekt: Er ist die Existenzberechtigung seiner selbst.
Das ist Käse.
Nach dieser "Philosophie" hätte keine komplexere Maschine eine
Existenzberechtigung, da sie ja auch nicht aus sich selbst hergestellt
wurde, sondern eine Kombination von vielen kleineren Teilen ist. Auch
sollte sich ein Schraubenschlüssel nicht einbilden, dass sein Typ oder
Hersteller für die Existenzberechtigung der Maschine großen Belang
hätte, nur weil er zum Bau benutzt wurde.
Proxxon schrob:
>Dann gäbe es auch das wunderbare Namenskonstrukt>Turbohorst 1.0
Das geht nicht, denn diesen Namen hat schon meine Garagennachbar inne...
@Yalu
Der Link von Dir ist prima! Ich bin also nicht der Einzige mit solchen
Gedankengängen...
;-)
MfG Paul
MWS schrieb:> Yalu X. schrieb:>> philosophischen Aspekt: Er ist die Existenzberechtigung seiner selbst.>> Das ist Käse.
Und du hast es nicht verstanden. Das musst du auch nicht, da es ohnehin
nicht todernst gemeint war.
Trotzdem ein paar Worte zu deinen Einwänden:
> Nach dieser "Philosophie" hätte keine komplexere Maschine eine> Existenzberechtigung, da sie ja auch nicht aus sich selbst hergestellt> wurde, sondern eine Kombination von vielen kleineren Teilen ist.
Das ist verkehrt herum geschlossen: Die komplexe Maschine stellt die
Existenzberechtigung für ihre Teile dar, nicht umgekehrt. Die Existenz-
berechtigung der Maschine selbst ergibt sich bspw. aus ihren Anwendungs-
möglichkeiten.
> Auch sollte sich ein Schraubenschlüssel nicht einbilden, dass sein Typ> oder Hersteller für die Existenzberechtigung der Maschine großen> Belang hätte, nur weil er zum Bau benutzt wurde.
Hier das Gleiche: Weil der Schraubenschlüssel einen sinnvollen Beitrag
zum Bau der Maschinene geleistet hat, ist er existenzberechtigt, nicht
unbedingt die Maschine.
Man könnte jetzt natürlich postulieren, dass die Nutzung eines Objekts A
zur Schaffung eines Objekts B nur dann eine Existenzberechtigung von A
impliziert, wenn auch B existenzberechtigt ist. Beim Compiler, der sich
selbst übersetzt, wäre dann A=B, was — wie man leicht zeigen kann — dazu
führt, dass das Postulat immer erfüllt ist, unabhängig davon, ob der
Compiler existenzberechtigt ist oder nicht. Man könnte dann also alleine
aus der Tatsache, dass der Compiler sich selbst übersetzt, nicht seine
Existenzberechtigung (aber auch nicht das Gegenteil) ableiten.
Das genannte Postulat ist aber ohnehin etwas fraglich: Akzeptiert man es
als richtig, hat entweder kein einziges Objekt dieser Welt eine Exis-
tenzberechtigung (das wäre schlimm), oder es muss mindestens ein Objekt
geben, das per Axiom als existenzberechtigt definiert wird. Was aber
könnte dieses Objekt sein? Vielleicht Gott? Oder der Kosmos? Oder Paul
Baumann?
Da es auf diese Frage es wohl kaum eine allgemein akzeptierte Antwort
geben wird (außer vielleicht Paul Baumann), ist es sinnvoller, das obige
Postulat zu verwerfen und einfach zu akzeptieren, dass ein Compiler, der
sich selbst übersetzt, eine inhärente Existenzberechtigung hat :)
Yalu X. schrieb:> Und du hast es nicht verstanden.
Doch, ich schon verstanden, Du nicht verstanden haben.
>> dass sein Typ oder Hersteller für die Existenzberechtigung> Hier das Gleiche: Weil der Schraubenschlüssel einen sinnvollen Beitrag
Ich rede von Typ und Hersteller (also im übertragen Sinn die verwendete
Programmiersprache) und Du redest vom Schraubenschlüssel an sich (in
beliebiger Form), Du möchtest also ablenken oder hast die Aussage nicht
verstanden.
Deshalb lassen wir mal Deine weiteren Obfuscating-Versuche außer acht
und machen dafür eine Textersetzung:
> einen Compiler in seiner eigenen Sprache zu schreiben> Er ist die Existenzberechtigung seiner selbst.
"Er" = "einen Compiler" = AVR GCC
"seiner selbst" = "seiner eigenen Sprache" = C
Also lautet Deine Aussage:
"AVR GCC ist die Existenzberechtigung für C"
Und das ist natürlich Unsinn, umgekehrt würde vielleicht ein Schuh
draus.
> Das musst du auch nicht, da es ohnehin nicht todernst gemeint war.
Hab's auch nicht so betrachtet.
@MWS
Sag mal im Ernst: Hat sich das in Deinem Beitrag von 10:24 Uhr wirklich
so übersetzen lassen? Wenn das so geht, dann wäre es ja eine einmalige
Möglichkeit, die Syntax von C erst mal außen vor zu lassen und sich mit
den Hürden der Sprache an sich zu befassen.
MfG Paul
> #define und &> #define alogischund &&> #define oda |> #define alogischoda ||> #define obaned !> #define isned !=> #define is =
Vielleicht lerne ich doch noch C ... :-)
Paul Baumann schrieb:> @MWS>> Sag mal im Ernst: Hat sich das in Deinem Beitrag von 10:24 Uhr wirklich> so übersetzen lassen? Wenn das so geht, dann wäre es ja eine einmalige> Möglichkeit, die Syntax von C erst mal außen vor zu lassen und sich mit> den Hürden der Sprache an sich zu befassen.>> MfG Paul
Also wenns schon an diesem Syntax scheitert, und eine einfache
Textersetzung die Rettung sein soll, würde ich mir den Rest auch gleich
sparen. Das hilft dann alles nichts mehr.
MWS schrieb:> Yalu X. schrieb:>> Und du hast es nicht verstanden.>> Doch, ich schon verstanden, Du nicht verstanden haben.
dto. ;-)
> Deshalb lassen wir mal Deine weiteren Obfuscating-Versuche außer acht> und machen dafür eine Textersetzung:>>> einen Compiler in seiner eigenen Sprache zu schreiben>> Er ist die Existenzberechtigung seiner selbst.>> "Er" = "einen Compiler" = AVR GCC
Nehmen wir besser den GCC für PCs, denn der AVR-GCC ist ein Cross-
Compiler und übersetzt sich deswegen nicht selber.
> "seiner selbst" = "seiner eigenen Sprache" = C
Nein, mit "seiner selbst" meine ich genau das, was ich geschrieben habe,
nämlich ihn, den Compiler.
> Also lautet Deine Aussage:> "AVR GCC ist die Existenzberechtigung für C"
Nein, sie lautet, übetragen auf das Beispiel:
> "Der GCC ist die Existenzberechtigung für den GCC"
Der GCC hat natürlich viele Existenzberechtigungen, das leitet sich aus
seiner großen Verbreitung ab. Aber selbst seine Verbreitung gegen null
ginge: Mindestens ein einziges Mal muss er genutzt worden sein (nämlich
um sich selbst zu compilieren), sonst würde er nicht existieren.
Wenn man allem, was mindestens einmal für irgendetwas genutzt wird, eine
Existenzberechtigung zuspricht, hat also der GCC eine. Und diese Exis-
tenzberechtigung leitet sich alleine von seiner Eigenschaft als "sich
selbst bauendes Programm" ab. Somit ist er seine eigene Existenzberech-
tigung. Das wollte ich oben ausdrücken :)
Paul Baumann schrieb:> Sag mal im Ernst: Hat sich das in Deinem Beitrag von 10:24 Uhr wirklich> so übersetzen lassen?
Ja, selbstverständlich, das hat sich nicht nur übersetzen lassen,
sondern auch das Richtige gemacht. Bevor ich so'n Schmarrn reinstell',
teste ich das natürlich. :-)
MWS schrieb:> Paul Baumann schrieb:>> Sag mal im Ernst: Hat sich das in Deinem Beitrag von 10:24 Uhr wirklich>> so übersetzen lassen?>> Ja, selbstverständlich, das hat sich nicht nur übersetzen lassen,> sondern auch das Richtige gemacht. Bevor ich so'n Schmarrn reinstell',> teste ich das natürlich. :-)
Wenn du dem Paul jetzt noch eröffnest, dass man mit den Defines C
auch an andere Sprachen als Bayerisch anpassen kann (Paul ist kein
Bayer), wird aus ihm sicherlich ein neuer C-Fan ;-)
@MWS
Ich staune deshalb, weil ich annahm, daß man "Schlüsselworte" so
hinzunehmen hat, wie sie in der Sprache "eingebaut" sind.
Du hast ja den Schlüsselworten eigene Namen als Ersetzung gegeben. Es
wunderte mich eben, daß der Kompiler da nicht hustet und spuckt.
MfG Paul
Thread beobachten
Seitenaufteilung abschalten