mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Programmkopf


Autor: ...! (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich sitze gerade in der Berufsschule und habe den Auftrag
bekommen, herauszufinden was

_CONFIG_PWRTE_ON&_WDT_OFF&_HS_OSC

bedeutet...

kann mir vllt jemand weiter helfen??

danke schon mal

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht sollte hier mal ein neues Forum eingeführt werden für Leute, 
die
a) absolut keine Ahnung haben, wovon sie reden
b) nicht in der Lage sind, ihre Hausaufgaben eigenständig zu bearbeiten 
und
c) es nicht einmal für nötig halten, die Forenregeln zu lesen...

Autor: Daniel F. (df311)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
42

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> kann mir vllt jemand weiter helfen??
Ja.

> _CONFIG_PWRTE_ON&_WDT_OFF&_HS_OSC
Wahrscheinlich
- ist es ein Mikrocontroller vom 8048-Derivat,
- du programmierst in ADA,
- das sind Compilerdirektiven ...

Falls das nicht so ist:
warum sagst du das nicht (so vollständig wie möglich)?
Das u.A. ist gemeint, wenn du aufgefordert wirst,
> die Forenregeln zu lesen


> _CONFIG_PWRTE_ON&_WDT_OFF&_HS_OSC
Such doch einfach mal im Manual oder im Forum nach diesen Kürzeln...
Seit es PDFs gibt, ist das soooo einfach.  ;-)

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...! wrote:
> _CONFIG_PWRTE_ON&_WDT_OFF&_HS_OSC

Ich glaube, in Bascom heißt alles irgendwie CONFIG, damit kein Schwein 
mehr durchsieht.


Peter

Autor: Karl-heinz Strunk (cletus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel F. wrote:
> 42

42 ist übrigens nur die Antwort auf die Frage nach dem Universum, dem 
Leben und dem Rest (oder so ähnlich), NICHT aber die Antwort auf 
ALLE Fragen.

Autor: michi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
falls es sich um einen PIC handelt, könnte das hier weiterhelfen

http://www.sprut.de/electronic/pic/config/config_emb.htm

gruß michi

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist ein PIC und die Zeile verknüpft drei Configuration Bits mit der 
bitweisen-UND (&) Verknüpfung.

Autor: Dominique Görsch (dgoersch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OT:
Peter Dannegger wrote:
> Ich glaube, in Bascom heißt alles irgendwie CONFIG, damit kein Schwein
> mehr durchsieht.

Langsam wird das Bascom-Bashing albern. Die Config-Direktiven von Bascom 
stehen fein säuberlich in der Hilfe erklärt und sind eigentlich schon 
vom Namen her sowas von Aussagekräftig.

Zumindest weiß ich auch ohne Hilfe, was ich z.B. mit
CONFIG LCD ...
CONFIG GRAPFHLCD ...
CONFIG 1WIRE ...
CONFIG DCF77 ...
CONFIG RC5 ...
CONFIG SPI ...
etc. konfiguriere. Mal ganz davon abgesehen, dass damit nicht nur die 
entsprechenden Ports/Pins für die jeweilige Sache konfiguriert werden, 
sondern auch die vollständige Initialisierung z.B. des LCD geschehen 
ist.
$regfile = "m16def.dat"
Config Lcdpin = Pin , Db4 = Portd.0 , Db5 = Portd.1 , Db6 = Portd.2 , Db7 = Portd.3 , E = Portd.4 , Rs = Portd.5
Config Lcd = 20 * 2
Config Dcf77 = Pina.0 , Timer = 1 , Inverted = 1
Config Date = Dmy , Separator = .
Enable Interrupts
Main:
Do
   Locate 1,1 : LCD time$
Loop
End
11 Zeilen Code für eine Funkuhr, machst du mir das in C oder Assembler 
nach?

Gruß
Dominique Görsch

Autor: klugscheißer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 11 Zeilen Code für eine Funkuhr, machst du mir das in C oder Assembler
> nach?
In C mit Makros -> geht. Wir würden aber nicht jedes Makro mit CONFIG_
beginnen lassen. ;-)

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dominique Görsch wrote:

> 11 Zeilen Code für eine Funkuhr, machst du mir das in C oder Assembler
> nach?

Ich gehe mal davon aus, daß diese DCF77-Uhr selbstverständlich auch eine 
RTC (Zeit+Datum+Sommerzeit mit Timer vom MC-Quarz abgeleitet) enthält, 
um Empfangsstörungen zu überbrücken.

Wo legt man die Quarzfrequenz für den MC fest?
Wo legt man das Ausgabeformat für time fest (Vornullenunterdrückung, 
12/24h, Wochentag usw.)?
Wo steht, wann zuletzt die DCF77-Prüfung einwandfrei war, d.h. die RTC 
mit dem DCF77 synchronisiert wurde?
Kann ich weitere Prüfungen hinzufügen?

Was mache ich, wenn meine Aufgabe von den vorgefertigten Legosteinchen 
abweicht (also typischer Weise immer)?
Kann ich diese modifizieren (kommentierter Bascom-Quelltext vorhanden) 
oder muß ich alles neu machen?


Peter

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Geht sogar in C noch kürzer.

#include "Dcf77_LCD.h"
int main()
{
   Dcf77_LCD_INIT();
   while(1)
      Dcf77_LCD_SHOW();
   return 0;
}

(gut man braucht noch ein Dcf77_LCD lib aber was anders macht Bascom ja 
auch nicht)

Autor: Dominique Görsch (dgoersch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter wrote:
> (gut man braucht noch ein Dcf77_LCD lib aber was anders macht Bascom ja
> auch nicht)

Ach und die ist beim avr-gcc dabei? Nicht? Schade, bei Bascom schon!
Natürlich kann man entsprechende Makros und Funktionen auch in anderen 
Sprachen selber schreiben, Bascom hat das meist benötigte schon mit an 
Board.

Autor: Daniel F. (df311)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl-heinz Strunk wrote:
> Daniel F. wrote:
>> 42
>
> 42 ist übrigens nur die Antwort auf die Frage nach dem Universum, dem
> Leben und dem Rest (oder so ähnlich), NICHT aber die Antwort auf
> ALLE Fragen.

"The Answer to the Great Question [...] Of Life, the Universe and 
Everything [...] Is [...] Forty-two", said Deep Thought, with infinite 
majesty and calm.

also auf die frage nach dem universum, dem leben und allem...

und meiner meinung nach ist es eine passende antwort auf eine frage ohne 
jegliche hintergrundinformation ;-)

Autor: Dominique Görsch (dgoersch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger wrote:
> Ich gehe mal davon aus, daß diese DCF77-Uhr selbstverständlich auch eine
> RTC (Zeit+Datum+Sommerzeit mit Timer vom MC-Quarz abgeleitet) enthält,
> um Empfangsstörungen zu überbrücken.

Empfangslöcher sind in dem Fall nur über den eigenen Timer mit internem 
Oszi oder ext. Quarz/Oszi abgedeckt (natürlich Zeit und Datum, ob 
Sommerzeit weiß ich nicht). Eine echte RTC via SPI ist aber auch nicht 
wirklich ein Problem.

Ob die Zeitfunktionen Sommer-/Winterzeit berücksichtigen könnte man aber 
einfach testen, indem man nicht DCF sondern direkt den Timer (CONFIG 
CLOCK = Timer1) nutzt und mit entsprechenden Datums- und Zeitwerten kurz 
vor der Zeitumstellung vorbelegt (TIMER$ = "hh:mm:ss", DATE$ = 
"mm/dd/yy").

> Wo legt man die Quarzfrequenz für den MC fest?
Entschuldige, die Zeile habe ich dir tatsächlich vorenthalten.
"$crystal = 8000000" steht hinter "$regfile ...". Es sind demnach 12 
Zeilen Basic-Code für ein funktionierendes Programm.

> Wo legt man das Ausgabeformat für time fest (Vornullenunterdrückung,
> 12/24h, Wochentag usw.)?
Das Ausgabeformat kannst du über Fusing() oder weiteren Zahlen- und 
Stringmanipulationen anpassen, am einfachsten dann, wenn du nicht time$ 
sondern _min, _hour und _sec nutzt.

> Wo steht, wann zuletzt die DCF77-Prüfung einwandfrei war, d.h. die RTC
> mit dem DCF77 synchronisiert wurde?
Wann müsstest du selber speichert, ob synchronisiert wurde steht in Bit 
7 von dcf_status.

> Kann ich weitere Prüfungen hinzufügen?
So wie es oben steht wird permanent mit dem DCF-Signal abgeglichen, du 
kannst das aber auch nur zu bestimmten Zeiten veranlassen oder selber 
triggern. Sogar um das ein- und abschalten des DCF-Moduls können sich 
die Bascom-Funktionen ootb kümmern (SWITCHPOWER=1, POWERPIN=PIND.1, 
POWERLEVEL = 1).

> Was mache ich, wenn meine Aufgabe von den vorgefertigten Legosteinchen
> abweicht (also typischer Weise immer)?
Dann schreibst du das benötigte eben drumherum. Es war nur ein Beispiel 
wie man recht einfach in Bascom Standardaufgaben realisiert und zu 
ersten Ergebnissen kommt. Man kann natürlich auch umfangreichere 
Anwendungen in Bascom (und auch anderen Basic-Derivaten) schreiben.

> Kann ich diese modifizieren (kommentierter Bascom-Quelltext vorhanden)
> oder muß ich alles neu machen?
In der Demo-Version sind soweit ich weiß alle Libs nur als Kompilate 
verfügbar, in der Vollversion auch als Quelltext (AFAIK überwiegend in 
Assembler).

Ich will hier sicher nicht Bascom propagieren, AVRs lassen sich ebenso 
in C oder ASM programmieren, aber Bascom ist nicht schlecht und das 
ständige Bascom bashing find ich inzwischen ziemlich erbärmlich und 
deklassiert für mich nur den Basher.

Gruß
Dominique Görsch

Autor: - - - (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Ich will hier sicher nicht Bascom propagieren, AVRs lassen sich ebenso
>>in C oder ASM programmieren, aber Bascom ist nicht schlecht und das
>>ständige Bascom bashing find ich inzwischen ziemlich erbärmlich und
>>deklassiert für mich nur den Basher.

Naja, ohne Dir zu nahe treten zu wollen, aber 'nen eingefleischten C-Fan 
werden diese Argumente trotzdem nicht überzeugen können.

mfg

Autor: Hampelmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In C kann man jegliches Programm in nur einer einzigen Zeile 
schreiben.., die wird nur u.U. recht lang...

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
- - - wrote:
> Naja, ohne Dir zu nahe treten zu wollen, aber 'nen eingefleischten C-Fan
> werden diese Argumente trotzdem nicht überzeugen können.
Doch, natürlich. Dominique hat mir grad die Augen geöffnet. Ich muss 
jeden Tag 100 DCF77-Uhren programmieren, und ich habe mich schon immer 
über die viele Tipparbeit geärgert. Ich werde zur BASCOM-Bruderschaft 
konvertieren und jedem erzählen, wie toll man mit BASCOM DCF77-Uhren 
programmieren kann. Die BASCOM-Jünger werden die Welt beherrschen! Nie 
mehr C! Lasset uns BASCOM in die Welt hinaustragen! Nur BASCOM ist die 
Lehre der Wahrheit!

Autor: Dominique Görsch (dgoersch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
- - - wrote:
> Naja, ohne Dir zu nahe treten zu wollen, aber 'nen eingefleischten C-Fan
> werden diese Argumente trotzdem nicht überzeugen können.

Ich will niemanden davon überzeugen etwas Anderes zu nutzen, aber muss 
man direkt alles Andere schlecht machen, nur weil man für sich pers. das 
Ideal gefunden hat?

Gruß
Dominique Görsch

Autor: Dominique Görsch (dgoersch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johannes M. wrote:
> Doch, natürlich. Dominique hat mir grad die Augen geöffnet. Ich muss
> jeden Tag 100 DCF77-Uhren programmieren, und ich habe mich schon immer
> über die viele Tipparbeit geärgert. Ich werde zur BASCOM-Bruderschaft
> konvertieren und jedem erzählen, wie toll man mit BASCOM DCF77-Uhren
> programmieren kann. Die BASCOM-Jünger werden die Welt beherrschen! Nie
> mehr C! Lasset uns BASCOM in die Welt hinaustragen! Nur BASCOM ist die
> Lehre der Wahrheit!

Geh' dich doch bitte weiter an deinem C-Code ergötzen, dass ist allemal 
sinnvoller als wenn du hier sinnfrei postest. Irgendwann wirst auch du 
dann begreifen, dass ein Beispiel exemplarisch zu verstehen ist.

Autor: Dominique Görsch (dgoersch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hampelmann wrote:
> In C kann man jegliches Programm in nur einer einzigen Zeile
> schreiben.., die wird nur u.U. recht lang...

Ja ganz toll, und in Perl schreib ich ganze Applikationen in eine Zeile 
die dann nichtmal mehr lesbare Sequenzen enthält.

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dominique Görsch wrote:
> Geh' dich doch bitte weiter an deinem C-Code ergötzen, dass ist allemal
> sinnvoller als wenn du hier sinnfrei postest. Irgendwann wirst auch du
> dann begreifen, dass ein Beispiel exemplarisch zu verstehen ist.
Erstens ist dieser ganze Thread furchtbar sinnlos, weshalb ein 
sinnloses Posting mehr auch nicht wirklich schlimm ist.

Zweitens ist die Hauptsinnlosigkeit dieses Threads dadurch entstanden, 
dass ein gewisser Herr Görsch mit tierischem Ernst auf PeDas Kommentar 
eingegangen ist. Ich kenne Herrn Görsch nicht persönlich, aber er ist 
vermutlich jemand, der zum Lachen in den Keller geht (nichts für 
ungut)...

Ich persönlich habe nichts gegen BASCOM, es gibt sicherlich auch viele 
Leute, die damit Sinnvolles anstellen, und die ganze Diskussion BASCOM-C 
ist in meinen Augen unsinnig. Jeder soll mit dem arbeiten, mit dem er am 
besten klarkommt. Wenn jemand sich für BASCOM begeistern kann, bitte...

Nur finde ich es immer wieder bezeichnend, wenn BASCOM-User darauf 
hinweisen, wie kurz die Programme sind, was sicherlich kein Kriterium 
für eine Programmiersprache für eine Hardware ist, bei der es i.e.L. 
nicht darauf ankommt, dass der Quellcode kurz ist, sondern das, was 
letztendlich auf den µC kommt. Diese Argumentation führt die Diskussion 
immer wieder ins Lächerliche. Auch wenn man mit BASCOM ebenfalls kurzen 
Maschinencode erzeugen kann, es ist Fakt, dass viele 
BASCOM-Programmierer (speziell Einsteiger) mit immer den selben Fragen 
hier im Forum auftauchen, die sie nur deshalb haben, weil sie durch die 
Kompaktheit des BASCOM-Quellcodes nicht mehr nachvollziehen können, was 
in dem zu programmierenden System überhaupt passiert.

Und ja, es gibt auch C-Programmierer, die mit ähnlichen Fragen ankommen, 
aber die sind anteilsmäßig zu vernachlässigen.

Autor: Bascomfehler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was in den Chip gebrannt wurde sieht hinterher eh keiner mehr.
Wichtig ist was hinten raus kommt.

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Diskussion ist schon von daher voellig unsinnig, da BASCOM 
hoechstwahrscheinlich in C geschrieben ist, ergo ist BASCOM nur eine 
Erweiterung von C. Die Diskussion ob BASCOM oder C besser ist, ist also 
so sinnvoll wie die, ob Erdbeereis oder Eis besser ist.

q.e.d. (Um dem Ganzen einen wissenschaftlichen Anspruch zu geben)

Autor: - - - (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Ich will niemanden davon überzeugen etwas Anderes zu nutzen, aber muss
>>man direkt alles Andere schlecht machen, nur weil man für sich pers. das
>>Ideal gefunden hat?

Natürlich nicht! Allerdings ist in diesem C-AVR-lastigen Forum nichtmal 
der PIC-Freund seiner selbst sicher.

PS:
Habe soweit alles mir wichtige durch, PIC's & AVR's in Assembler & C, 
bei ARM laß ich derweil die ARMe hängen, weil ich mit den Startup-Codes 
nict klarkomme, weil es niemand erklären will oder kann. Siehe Board.

mfg

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johannes M. wrote:

> Und ja, es gibt auch C-Programmierer, die mit ähnlichen Fragen ankommen,
> aber die sind anteilsmäßig zu vernachlässigen.

Dann liest du wohl ein anderes Forum. Ich kann mich an die letzte 
BASCOM-Frage kaum erinnern, an manchen Tagen gibt es aber gleich ein 
halbes Dutzend anfragen, wie man in C eine Zahl als Text ausgibt...

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Stegemann wrote:
> Dann liest du wohl ein anderes Forum. Ich kann mich an die letzte
> BASCOM-Frage kaum erinnern, an manchen Tagen gibt es aber gleich ein
> halbes Dutzend anfragen, wie man in C eine Zahl als Text ausgibt...
Das hat ja auch nicht direkt etwas mit der Controller-Hardware zu tun. 
Die typischen BASCOM-Fragen tendieren thematisch eher in andere 
Richtungen.

Aber Du hast schon Recht: Insgesamt ist es BASCOM-mäßig in letzter Zeit 
eher ruhig geworden. Hat da jemand einen BASCOM-Filter eingebaut;-? Oder 
haben die BASCOM-Entwickler die Dokumentation verbessert? Ich weiß es 
nicht, aber ich habe nach wie vor nichts pauschal gegen BASCOM...

Autor: Dominique Görsch (dgoersch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johannes M. wrote:
> Ich kenne Herrn Görsch nicht persönlich, aber er ist
> vermutlich jemand, der zum Lachen in den Keller geht (nichts für
> ungut)...

Mitnichten, ich finde einfach nur dieses Bascom-Bashing ist total 
unnötig - und das nicht, weil ich Bascom-Nutzer bin. Ebenso das 
Linux-Bashing, Windows-Bashing, oder diverse andere Flamewars. 
Überlicher Weise gibt's bei Glaubenkriegen ohnehin nur verlierer. Im 
Übrigen kannst du mich gerne beim Vornamen nennen - auch ein Domi ist 
vollkommen ok... aber wenigstens "Herr", das bin ich auch anders 
gewohnt. ;)

> Ich persönlich habe nichts gegen BASCOM, es gibt sicherlich auch viele
> Leute, die damit Sinnvolles anstellen, und die ganze Diskussion BASCOM-C
> ist in meinen Augen unsinnig. Jeder soll mit dem arbeiten, mit dem er am
> besten klarkommt. Wenn jemand sich für BASCOM begeistern kann, bitte...

Genau das ist doch der Punkt. Ich nehme mir das Recht und die Freiheit 
zur Lösung (m)eines Problems aus meinem Portfolio zu dem meiner Meinung 
nach bestem Werkzeug zu greifen. Bisher war das für mich beim Thema AVR 
immer Bascom, ich bin noch nicht an seine Grenzen gestossen. Für die 
x86-Welt oder das Web beherrsche ich noch ein paar andere Sprachen, wenn 
auch Basic (VBA, VB 6 und .NET) klar zu meinen Stärken gehört. Ich käme 
aber sicher nie auf die Idee auf Biegen und Brechen ein Problem in Basic 
zu lösen, wenn vielleicht drei Zeilen Perl, Python, Ruby oder was auch 
immer besser geeignet wären (Perl's Stärken sind ja nunmal z.B. die 
Stringmanipulation).

> Nur finde ich es immer wieder bezeichnend, wenn BASCOM-User darauf
> hinweisen, wie kurz die Programme sind, was sicherlich kein Kriterium
> für eine Programmiersprache für eine Hardware ist, bei der es i.e.L.
> nicht darauf ankommt, dass der Quellcode kurz ist, sondern das, was
> letztendlich auf den µC kommt.

Die Codelänge ist schon mit ein Kriterium, insb. wenn es auf die 
Etwicklungszeit ankommt. Ein paar Zeilen lauffähiger Code sind schneller 
geschrieben, als wenn ich mich von Hand erst um die Initialisierung der 
gesamten Peripherie kümmern muss.

> Auch wenn man mit BASCOM ebenfalls kurzen
> Maschinencode erzeugen kann, es ist Fakt, dass viele
> BASCOM-Programmierer (speziell Einsteiger) mit immer den selben Fragen
> hier im Forum auftauchen, die sie nur deshalb haben, weil sie durch die
> Kompaktheit des BASCOM-Quellcodes nicht mehr nachvollziehen können, was
> in dem zu programmierenden System überhaupt passiert.

Das Problem sehe ich da eher anders. Aufallend ist, dass viele sehr 
dumme Fragen aus dem Bascom-Umfeld kommen. Ich denke das liegt daran, 
dass Bascom von vielen als sehr einfach empfunden wird und daher viele 
Anfänger dazu greifen. Das übliche Problem vieler Anfänger ist der 
fehlende Wille Datenblätter, Handbücher und andere Dokumentation zu 
lesen.

> Und ja, es gibt auch C-Programmierer, die mit ähnlichen Fragen ankommen,
> aber die sind anteilsmäßig zu vernachlässigen.

Hab ich noch nie so wirklich drauf geachtet, mag aber stimmen.

Gruß
Dominique Görsch

//EDIT:
Vermutlich gibt es zwei Klassen oder besser zwei Sorten von Anfängern: 
die eine Klasse möchte einfach möglichst schnell und mit wenig Aufwand 
zum Ziel, diese Gruppe greift dann gerne zu Bascom und wenns nicht so 
tut wie gewollt tauchen hier die "dummen Fragen" auf. Die andere Gruppe 
will aber auch verstehen was im µC wirklich passiert. Die arbeiten das 
AVR-Tut durch und landen dann entweder bei ASM oder bei C. Wirklich 
dumme Fragen haben sie nicht, da sie schon vorher einiges an Doku 
gelesen haben.

Ich glaub ich würde mich in die Mitte, aber mit deutlichem Hang zur 
ersten Gruppe einsortieren. Ich wollte auch erstmal Ergebnisse und 
nachher hat mich interessiert was passiert. Dafür finde ich z.B. die 
"Assemblereinführung für Bascom-User"[1] sehr gelungen.

[1]http://www.roboternetz.de/wissen/index.php/Assembl...

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dominique Görsch wrote:
> Die Codelänge ist schon mit ein Kriterium, insb. wenn es auf die
> Etwicklungszeit ankommt.
Richtig, sie ist aber nicht das alleinige Kriterium...

> Ein paar Zeilen lauffähiger Code sind schneller
> geschrieben, als wenn ich mich von Hand erst um die Initialisierung der
> gesamten Peripherie kümmern muss.
Wenn es nur die Initialisierung wäre... Da gibt es für C übrigens ne 
ganze Reihe sog. Code Generation Wizards, bei denen man mit Klickibunti 
sich die Peripherie zusammenfuddeln kann und der Initialisierungscode 
automatisch erstellt wird. Der Code glänzt dann allerdings oft durch 
erhebliche Wartungsunfreundlichkeit...

> Das Problem sehe ich da eher anders. Aufallend ist, dass viele sehr
> dumme Fragen aus dem Bascom-Umfeld kommen. Ich denke das liegt daran,
> dass Bascom von vielen als sehr einfach empfunden wird und daher viele
> Anfänger dazu greifen.
Ist sicher die Hauptursache für die Vorurteile.

> Das übliche Problem vieler Anfänger ist der
> fehlende Wille Datenblätter, Handbücher und andere Dokumentation zu
> lesen.
Das Datenblatt-Lese-Verweigerungssyndrom ist aber auch in anderen 
Kreisen verbreitet. Und wirklich "dumme" Fragen habe ich auch schon von 
nicht-BASCOMern gelesen.

> Gruß
> Dominique Görsch

Gruß zurück.

Johnny

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dominique Görsch wrote:
> Das übliche Problem vieler Anfänger ist der
> fehlende Wille Datenblätter, Handbücher und andere Dokumentation zu
> lesen.

Genau das ist der Punkt. Wenn jemand Fragen stellt, die im Datenblatt 
ausdrücklichst beantwortet werden, dann bekommt der Fragensteller hier 
im Forum eines drauf (und das meiner Meinung nach zu recht, denn es 
senkt ganz einfach das Niveau des gesamten Forums, und es nervt ganz 
einfach wenn jeden Tag das gleiche gefragt wird.) Wenn es dagegen eine 
einfache Frage ist, die aber sinnvoll ist, dann bekommt man hier auch 
schnell eine gute  Antwort.

>> Und ja, es gibt auch C-Programmierer, die mit ähnlichen Fragen ankommen,
>> aber die sind anteilsmäßig zu vernachlässigen.

Genau. Bei dummen Fragen ist die Sprache egal, nur sind es leider sehr 
häufig Leute die in BASCOM Programmieren und das Datenblatt nicht 
gelesen haben, denn in C ist es nahezu unmöglich auch nur irgendwas 
sinnvolles zu machen ohne zumindest mal die Grundlagen im Datenblatt 
gelesen zu haben.
Aber wenn es doch mal einer schafft, wird der hier im Forum genauso 
nieder gemacht, wenn er eine leicht durch das Datenblatt zu 
beantwortende Frage stellt.

Und da statistisch gesehen BASCOM nunmal verstärkt von Leuten mit 
wenig/keiner Ahnung genutzt wird, hat BASCOM nunmal ein entsprechendes 
Image.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dominique Görsch wrote:
> Ich will hier sicher nicht Bascom propagieren, AVRs lassen sich ebenso
> in C oder ASM programmieren, aber Bascom ist nicht schlecht und das
> ständige Bascom bashing find ich inzwischen ziemlich erbärmlich und
> deklassiert für mich nur den Basher.

Danke für die Beantwortung der Fragen.

Der kleine Seitenhieb war doch nicht so ernst gemeint. Er fußte ja 
darin, daß der Ursprungspost für die meisten völlig unverständlich war.


Peter

Autor: Gasst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>_CONFIG_PWRTE_ON&_WDT_OFF&_HS_OSC

Nach erfolgreicher Hinrichtung des Fragestellers versuche ich einmal 
eine Übersetzung:

Stelle Programmschreiben auf EIN &
mache den Wachhund AUS &
wähle den Hochgeschwindigkeits-Oszillator.

Irgendwelche Einwände?
Na dann ist gut :-)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.