Schon gesehn, Avr Wettbewerb !

Bastler wrote:
> Auf der Seite
> http://www.shop.robotikhardware.de/shop/catalog/news_zeigen.php?id_news=27
> gibt einen interessanten AVR Wettbewerb.

Die Software muss (zumindest teilweise) in BASCOM geschrieben sein, 
somit dürften die wirklich guten Projekte wegfallen. Selbst schuld wer 
solche dummen Regeln aufstellt.

>Die Software muss (zumindest teilweise) in BASCOM geschrieben sein,

Da kann man mal raten wer das Preisgeld gestiftet hat ;-)

ich zitiere:
Mit der Einsendung erlaubst du die lizenzkostenfreie Veröffentlichung 
und den Nachbau und Ausbau des Projektes! Ebenfalls gestattest du die 
Veröffentlichung im Roboternetz.de oder auf der Robotikhardware CD.

Ich sage einfach mal frech dass die damit Geld verdienen wollen.
(zb.: mit bausätzen oder sowas....)

Gruß Anselm

...der nächste Pollin Bausatz!

Der Ansatz "für die breite Masse" beißt sich aber etwas mit BASCOM.
Da wäre C sinnvoller.

Da bist du aber Fern von der Realität! Fast 70% der AVR Anwender 
verwenden Bascom. In meinem Bekanntenkreis sind es sogar 90% !

>Du glaubst doch nicht wirklich, dass irgendwo in der Industrie mit
>BASCOM programmiert wird!?!

Nein, das glaube ich nicht. Das weiß ich.

gez. Katapulski

>das sämtliche Programmierer bei mir in der Firma...
Wieviele Programmierer gibt es bei Dir in der Firma außer Dir selbst? 
;-)

SCNR
Katapulski

>Ich bin also gar kein richtiger Programmierer.

Der war gut! Wenn DU kein richtiger Programmierer bist, wer dann?

Hut ziehend
Katapulski

Ach so: Zurück zu der Frage, ob BASCOM nicht nur von Bastlern verwendet 
wird. Ich habe hier 3 Leute, die ein Ingenieurbüro führen. Sie schreiben
eine ganze Menge ihrer Sachen damit. Dabei geht es vor Allem um einfache
Ablaufsteuerungen für Maschinen, von denen oft nur ein Exemplar gebaut 
wird. Dort sind die Abläufe nicht so zeitkritisch und es kommt nicht 
darauf an, das letzte Byte im Flash nicht zu belegen. ;-)
Ich selbst bin auch ein Fan davon, wobei ich in letzter Zeit auch an
AVR-Assembler nicht vorbeigekommen bin, denn die Library-Dateien in 
Bascom
sind ja auch in Assembler geschrieben. Wenn man daran etwas zu ändern 
hat,
muß man ja verstehen, was dort vorgeht.

gez. Katapulski

na is das nich generell so?
kleine sachen bzw projekte die nicht wirklich zeitkritisch sind werden 
in bascom geschrieben..aber sobald es auf genaue zeiten ankommt nimmt 
man c oder besser assembler?

wobei ich mir assembler recht schwer vorstellen wenns um sehr große 
projekte geht?

also ich habe bisher genau 0 mal in basic programmiert und bin ehrlich 
gesagt stolz drauf. gut ich bin nicht normal und nicht der nabel der 
welt, aber basic habe und werde ich nie einsetzen.

ps: ja. asm und richtig grosse projekte sind nicht wirklich lustig, aber 
geschickt passagen per inline asm rein gefrickelt oder spezielle 
funktionen... das ist durchaus akzeptabel bis sinnvoll.


senf

> also ich habe bisher genau 0 mal in basic programmiert und bin ehrlich
gesagt stolz drauf. gut

Bist du noch keine 14? So ein Schwachsinn kenne ich eigentlich nur von 
jungen Schülern die meist weder C, Assember noch Basic auch nur 
annährend beherrschen. Sie meinen wenn Sie in C etwas kleines 
zusammenfriemeln wären Sie Könner. Die haben nicht verstanden um was es 
geht und werden es vermutlich auch nie. Beim Programmieren geht es um 
Aufgaben, Ziele, Problemstellungen die in möglichst kurzer Zeit mit 
möglichst geringen Aufwand durch geeignete Algorithmen perfekt gelöst 
werden müssen. In den meisten Fällen ist man mit Bascom hier viel 
produktiver und das zu erkennen, das zeichnet den Profi-Programmierer 
aus. Sicher gibt es auch Aufgaben wo C und Assembler angesagt ist, auch 
das muss dann ein Profi erkennen, aber das ist relativ selten der Fall.

hmmm ruby... neumodisches zeuch... perl oder sed/awk und gut is. ack.

Michael S. wrote:

> Es kommt drauf an, dass man versteht, was man machen möchte. Eine
> Programmiersprache ich der Weg zum Ziel, nicht mehr und nicht weniger.

Wenn das Ziel lautet: Möglichst portablen Code zu erzeugen, dann ist 
BASCOM aber nunmal der falsche weg. Denn es ist und bleibt ein 
proritärer Compiler. Für kleine Quick&Drity Projekte vielleicht ok, ab 
wenn das Projekt in 5 Jahren vielleicht mal neu auf einem größeren µC 
laufen soll, dann ist BASCOM eindeutig die falsch Wahl. Und wenn es 
irgendwann MSC nicht mehr gibt gibt, kann man alles nochmal neu 
programmieren.

@gast:
proprietär, das meinst ;)
Die größte Schwäche von Basic ist die Nichteinhaltung von Normen. Jeder 
Compiler kocht sein eigenes Süppchen - aber in den Grundzügen passt es 
dann doch wieder.
Ich selbst programmiere (inzwischen) sehr gern mit C, früher war ASM 
mein Favorit - aber Basic hat auch seinen Reiz.
Basic haften von früher viele Vorurteile an, es sei langsam, ineffektiv. 
Wenn man sich den C64-Interpreter mal genauer anschaut, sieht man auch, 
dass der damalige Programmierer alles getan hat, es langsam zu machen 
(da wundert dann nicht mehr, dass dieses Basic von Microsoft kam).
Inzwischen ist Basic schon lange erwachsen geworden und kann es 
problemlos mit anderen Sprachen aufnehmen.
Schlußendlich ist es eine Frage der Umsetzung. Während man bei C ständig 
im Datenblatt schauen muss, welches Bit in welchem Register gesetzt 
werden muss, ist es bei Basic eben die Befehls-Referenz ;)
Schlussendlich muss man zugeben, dass Bascom für µC-Anfänger ein 
wesentlich einfacherer Einstieg als C ist. Ich habe schon min. 5 
Anfängern Bascom empfohlen, und alle sind sehr zufrieden, weil 
unglaublich schnell Ergebnisse erzielt werden. Ich selbst bin noch ein 
Wackelkandidat, mir ist Bascom noch etwas zuviel "Black-Box", man 
bekommt schon zuviel Arbeit abgenommen - aber ich wanke bereits ;)

Halle Leute,
wenn man hier liest wird man das Gefühl nicht los dass sich in diesem 
Forum eine Unmenge ignorranter Dummköpfe bewegen.
Ich schreibe seit fast 30 Jahre Software und hatte nie ein Problem mit 
einer Programmiersprache. Meine ersten Programme wurden noch auf einem 
Blatt Papier codiert und dann mit einer 16er Tastatur in den Controller 
gehackt (war übrigens bereits ein 8048). Lange Zeit gab es für mich 
nichts anderes als Assembler. Als erste Hochsprache habe ich Basic 
gelernt, war ein Horror aber nicht wegen der Sprache. Mit der 
Hochsprache wusste ich plötzlich nicht mehr was die Hardware wann 
tatsächlich tut. Ich habe Industriesteuerungen mit Basic programmiert, 
da dieses Basis damals die einzige Programmiersprache war welche in 
ihrer Syntax Befehle zur Unterstützung von Multitasking enthielt. Ich 
habe aber auch Programmiersprachen benutzt, welche viele von Euch nicht 
mal kennen (kleiner Auszug Fortran, Ada, Forth, Smalltalk, ...). Wichtig 
bei einer Problemlösung ist aber das WIE und nicht das WOMIT.
Daher lasst diejenigen, welche gerne Software in Basic schreiben, diese 
in Basic schreiben, diejenigen die C lieben werden ihre Programme in C 
schreiben, andere verwenden Assembler, Pascal oder Java. Wenn das 
Ergebnis dem Ziel angemessen ist ist das doch OK.

Wenn ein Wettbewerb eine Programmiersprache vorschreibt wird das seine 
Gründe haben, seien diese kommerziell oder auch anderer Natur. Ich kenne 
das Roboter-Forum und weiss, dass dort ein Grossteil der Leute in Bascom 
programmiert, vielleicht ist auch das der Grund.
Und wer an diesem Wettbewerb nicht teilnehmen möchte, kann es ja bleiben 
lassen. Wer aber gierig auf den Gewinn von € 500,- ist, der soll die 
Bedingungen akzeptieren und nicht maulen.

Gruss an alle und weiter viel Spass
ein Alter Hase

marvin m. wrote:
> Schlussendlich muss man zugeben, dass Bascom für µC-Anfänger ein
> wesentlich einfacherer Einstieg als C ist. Ich habe schon min. 5
> Anfängern Bascom empfohlen, und alle sind sehr zufrieden, weil
> unglaublich schnell Ergebnisse erzielt werden.

Da stimme ich dir uneingeschränkt zu. Es ist einfach, aber es nimmt 
einem das selbständige Denken zumindest teilweise ab, und das ist 
gefährlich:

> Schlußendlich ist es eine Frage der Umsetzung. Während man bei C ständig
> im Datenblatt schauen muss, welches Bit in welchem Register gesetzt
> werden muss, ist es bei Basic eben die Befehls-Referenz ;)

Es gab hier im Forum schon Leute, die Software in BASCOM in der 
Codesammlung für ein Oszilloskop mit einem AVR gepostet haben, im Code 
übelst rumgepfuscht haben, um eine hohe Datenrate AVR->PC zu erzielen, 
aber nichtmal wussten dass es einen ADC Prescaler gibt, mit dem man die 
ADC Taktrate und somit die Samplerate einstellen kann (der daher mit 
einem langsamen Takt lief, weshalb die Messungen einfach nur Mist 
waren). Sowas kann ich C nicht passieren, denn denn wenn man die 
Register nicht selbst setzt, setzt sie keiner, und das merkt man 
schnell.
Und wenn man hier im Forum liest, merkt man schnell, dass es vor allem 
Leute sind die in BASCOM programmieren, die bei kleinsten Problemen die 
es so nicht vorgefertigt gibt, aufgeben, da sie mit dem Datenblatt 
überfordert sind (bzw. nichtmal wissen dass es hilfreich wäre das mal zu 
lesen).
Das ist der Grund wieso zumindest ich kein BASCOM mag: Man kann zwar 
programmieren, aber hat letzendlich Null Ahnung von einem µC, wenn man 
aktiv nichts dagegen unternimmt. In C wird man quasi zur Selbständigkeit 
gezwungen.

>Das ist der Grund wieso zumindest ich kein BASCOM mag: Man kann zwar
>programmieren, aber hat letzendlich Null Ahnung von einem µC, wenn man
>aktiv nichts dagegen unternimmt. In C wird man quasi zur Selbständigkeit
>gezwungen.

Das stimmt so nicht. Die Lernkurve ist nur anders. In Bascom steigt man 
tatsächlich ohne tiefere Microprozessorkentnisse ein und kommt auch 
schnell zum Ziel, dem fertigen Programm. Erst nachdem an einige 
Programme geschrieben und höhere Anforderungen an da sProgramm hat lernt 
man STück für Stück die internen Eigenschaften des Controllers kennen. 
Da hilft übrigens auch die gute Bascom Dokumentation kräftig beim 
lernen.

C und erst Recht Assembler programmierer quelen sich von Anfang an duch 
das Microcontroller Interna. Sie sind froh wenn Sie nach Stundne von 
Arbeit endlich ein paar Buchstaben zum PC sendne können - also Aufgaben 
die Bascom in einer Zeile erledigt. Das führt dazu das C und Assembler 
Einsteiger nicht selten nach Tagen oder Wochen die Lust verlieren und 
den Mikrocontroller nie mehr anfassen.

Also mir ist der bequeme Weg lieber, zumal er keinen Nachteil bietet. 
Und wie man stolz sein kann eine Programmiersprache "nicht zu können" 
ist mir auch schleierhaft. Man muss nicht alle können, aber darauf muss 
man trotzdem nicht stolz sein.

Zum einen gibt es Array´s und zum anderen kann man auch direkt auf 
Speicherstellen zugreifen, was in etwa einem Pointer entspricht.
Das nur einzelne Rechenoperationen pro Zeile möglich sind ist in der Tat 
ein kleines verbesserungswürdiges Manko von Bascom, allerdings solltest 
du sowas erstmal in Assembler machen - dort brauchst du zahlreiche 
Zeilen für solch kleine Operationen. Da gibts übrigens auch keine 
Strukturen.

Natürlich gibts für Bascom auch Lib´s für TCP und Filesysteme, alles 
kein Problem.
In jedem Fall ist ein Bascom Programm im Source wesentlich kürzer als 
ein C Programm und zudem wesentlich besser lesbar. gerade deshalb ist es 
ja so beliebt.

Der [?]-Code ist nicht portabel... wenn ich das nur schon hoere... Ist 
er eh nicht. Weder in C noch in sonstwas. Ausser vielleicht auf den 
naechst groesseren AVR. Portabilitaet bedeutet die Idee ist portabel, 
nicht der Code. Und um die Idee bestmoeglich portieren zu koennen muss 
die Spache uebersichtlich und intuitiv sein. Leider gehoert u+=(1<<1) 
nicht dazu.

Wettbewerbe dienen dazu guenstig zu neuen Ideen und Talenten zu kommen.

... Ich bin also gar kein richtiger Programmierer. ...

Das stimmt.

05 FOR I=1 to 1000
10 PRINT "BASCOM kenne ich nicht... ";
15 NEXT i

5 FOR I=1 to 1000
10 PRINT "BASCOM kenne ich nicht... ";
15 NEXT i
20 GOTO 5
RUN

>Davon habe ich nicht geredet, sondern von Funktionspointern.
>Funktionspointer (Callbacks) werden in größeren Programmen sehr häufig
>benötigt.


Bascom ist sehr maschinennah! Natürlich kannst du auch Adressen direkt 
anspringen und manipulieren was dann einem Funktionspointer entspricht. 
Du kannst auch mitten im Code Assembler Code einfügen.
Aber gewöhnlich ist der Pointer Kram in Bascom garnicht notwendig, was 
die größte Fehlerquelle der C-Programmierer vermeidet

Wenn jemand mal versucht hat, mit einem 12F675/etc Video-Signale zu 
erzeugen, weiss genau, dass es hier auf den letzten CPU-Cycle ankommt, 
damit das Timing stimmt.

Da geht kein BASIC! Auch bei einem Software-UART geht kein BASIC (es sei 
denn, dieses hat effiziente ASM-Librarys eingebaut).

Ausschnitt einer Video-Generator Routine

1

      ......

2

      RLF    GPIO,F    ;ROTATE BIT 6 OUT OF CARRY

3

      RLF    INDF,W    ;ROTATE BIT 7 INTO CARRY

4

      RLF    GPIO,F    ;ROTATE BIT 7 OUT OF CARRY

5

      BCF    GPIO,0

6

      BTFSC  LINECTR,2    ;CHECK IF ON 5TH LINE

7

      BSF    GPIO,0    ;MAKE A SEPARATOR DOT

8

      NOP          ;MAKE DOT SAME SIZE

9

      BCF    GPIO,0    ;REMOTE THE DOT, IF ANY ;;22 INSTRUCTIONS... 4.4 US

10

      BTFSC  FSR,1    ;SKIP IF DATE OUTPUTED

11

      GOTO  PUTTIME

12

      INCF    FSR      ;NEXT VRAM LOCATION

13

      .....

Wenn man solche Realtime Anwendungen macht, dann muss man ASM 
programmieren.
Mit Realtime meine ich Mikrosekunden! Der Vorteil ist jener, dass der 
Programmierer selbst optimieren kann. Man muss einen Kompromiss zwischen 
Geschwindigkeit (CPU-Cycle) und Speicherbelegung (RAM, ROM) machen.

Vor allem, da man in einem 12F675 keinen Hardware-Shifer (SPI) oder 
andere HIlfsmittel hat.
Ausserdem muss man mit dem RAM (64 Bytes) und dem ROM/Flash (1K Words) 
auskommen.

Wenn man nur Taster abfragt, ist das egal, oder wenn man Aufgaben, die 
mit 5 MIPS zu schaffen sind auf einem ARM7TDMI macht.

Man sollte den MCU nicht als "Blackbox" betrachten!

>Wenn jemand mal versucht hat, mit einem 12F675/etc Video-Signale zu
>erzeugen, weiss genau, dass es hier auf den letzten CPU-Cycle ankommt,
>damit das Timing stimmt.


Sicherlich sind solche Spezialanwendungen nur mit etwas Assemblercode 
machbar, das will keiner bestreiten. Aber es spricht ja nix dagegen das 
man solchen Code in ein Bascom Programm einbettet. Es gibt übrigens 
sowas schon für Bascom!