Hallo miteinander,
weil mir immer wieder auffällt wie praktisch die Arduino IDE ist, wollte
ich mal in die Runde fragen warum alles andere so kompliziert
ist/scheint?
Folgendes sehe ich als Vorteil von Arduino:
-Compiler, Editor, Treiber sind in EINEM Zip Archiv enthalten!
-Entpacken und Starten / Keine Installation nötig
-Booloader direkt aus der IDE flashen
-Direktes flashen per ISP möglich
-Unerstützte Hardware kann erweitert werden
-Unterschiedliche Versionen parallel nutzbar
-Libraries können sehr einfach hinzugefügt werden
-Beispielcode für jede Lib integrierbar
-sowohl einfache Programmierung wie z.B. mit DigitalRead(),
DigitalWrite als auch Standard AVR-GCC möglich z.B. PORTB ^= ( 1 << PB0
);
Den einzigen Nachteil den ich erkennen kann, ist der notdürftige Editor,
der dennoch für die meisten Projekte ausreichend ist.
Natürlich kann ich nur aus meiner Sicht als Hobby Arduino Bastler
sprechen aber damit bin ich immer gut zum Ziel eines Projekts gekommen.
Wenn es nur so einfach wäre einen PIC oder STM32 zu programmieren / zu
flashen....
Deshalb die Frage warum muss man für alles andere einen gefühlt hohen
Aufwand treiben um z.B. nur mal eine LED an einem STM32 µC blinken zu
lassen?
Grüße
ArduFAN schrieb:> Natürlich kann ich nur aus meiner Sicht als Hobby Arduino Bastler> sprechen aber damit bin ich immer gut zum Ziel eines Projekts gekommen.
Genau dafür ist das konzipiert.
Aber wenn die Aufgaben größer werden, freut man sich über eine große
Entwicklungsumgebung.
Besonders im Bereich debugging. Und nein, Textzeilen per UART ausgeben
ist für mich kein vernüftiges debugging!
ArduFAN schrieb:> Folgendes sehe ich als Vorteil von Arduino:> -Compiler, Editor, Treiber sind in EINEM Zip Archiv enthalten!
Nachteil: Man ist auf eine einzige Kombination aus
Compiler+Treiber+Editor fixiert. Keine Auswahl.
> -Entpacken und Starten / Keine Installation nötig
Nachteil: Dateitypen werden nicht assoziiert, kein Startmenü-Eintrag
etc. Treiber muss manuell installiert werden.
> -Booloader direkt aus der IDE flashen
Flashen, ob Bootloader oder normales Programm, kann wohl jede
Embedded-IDE.
> -Direktes flashen per ISP möglich
Dito.
> -Unerstützte Hardware kann erweitert werden
Hab noch nie gehört, dass eine IDE die Erweiterungsmöglichkeit der zu
programmierenden Hardware einschränkt...
> -Unterschiedliche Versionen parallel nutzbar
Nachteil: Verleitet dazu veraltete Versionen zu nutzen.
Können andere IDE's aber auch.
> -Libraries können sehr einfach hinzugefügt werden
Bei welcher IDE geht das nicht?
> -Beispielcode für jede Lib integrierbar
Dito
> -sowohl einfache Programmierung wie z.B. mit DigitalRead(),> DigitalWrite als auch Standard AVR-GCC möglich z.B. PORTB ^= ( 1 << PB0> );
Nachteil: Wenn man nur den direkten Register-Zugriff verwendet, hat man
trotzdem die ganze Library im Projekt. Aber Libraries hinzufügen geht in
anderen IDE's natürlich auch.
ArduFAN schrieb:> Den einzigen Nachteil den ich erkennen kann, ist der notdürftige Editor,> der dennoch für die meisten Projekte ausreichend ist.
Für die meisten 10-Zeiler vielleicht... Bei richtigen Projekten mangelt
es doch stark an vernünftiger Dateiverwaltung, Auto-Completion,
Versionskontrolle, Refactoring-Funktionen, Projekt-Management,
Debugging, etc. etc.
ArduFAN schrieb:> Deshalb die Frage warum muss man für alles andere einen gefühlt hohen> Aufwand treiben um z.B. nur mal eine LED an einem STM32 µC blinken zu> lassen?
Du kannst ja eine extra-einfache STM32-IDE bauen, mit der man LED's
blinken lassen kann. Da aber STM32-Projekte im Allgemeinen viel mehr tun
sollen, braucht man dafür auch anständige IDE's.
ArduFAN schrieb:> Deshalb die Frage warum muss man für alles andere einen gefühlt hohen> Aufwand treiben um z.B. nur mal eine LED an einem STM32 µC blinken zu> lassen?
Es geht das Gerücht um das moderne MCUs mehr können als LEDs blinken zu
lassen.
Hinter dem 'einfachen' der Arduino IDE steht eine gigantische
Recourcenverschwendung um das einfach aussehen zu lassen.
Zwei mal hintereinander digitalScheissdreck() auf einen Port pin gibt
irgendwas mit 5us Puls (Mega128).
Das ist eine lächerlich lange Zeit.
Mal AVR Studio angeschaut ?
Das ist so ungefähr 2000 mal nützlicher als die Arduino IDE und ich kann
wirklich debuggen, in die Register schauen und zur Laufzeit
manipulieren.
Pin debugging oder per serieller Schnittstelle, die dann tot ist für
alles andere ist für mich einfach indiskutabel.
Arduino ist netter kleiner Bastelkram für den kleinen Hunger
zwischendurch.
Nicht mehr.
Wenn Dir alles ausserhalb Arduino zu schwierig ist und Dir der Krams
performant genug ist, warum bleibst Du nicht dabei ?
ArduFAN schrieb:> Natürlich kann ich nur aus meiner Sicht als Hobby Arduino Bastler> sprechen aber damit bin ich immer gut zum Ziel eines Projekts gekommen.
Das ist schon richtig. Arduino ist was wenn ich schnell ein
Standartprojekt hinklatschen will. Wenn du aber ein richtiges Projekt
hast in das du viel Zeit investierst, dann macht es nichts, dass du eine
Stunde brauchst (wenn überhaupt) bis die Toolchain steht. Keiner sagt,
dass das gut ist. Arduino führt halt alle absoluten Standart-Funktionen
raus. Aber sobald du diesen Bereich der Standarts verlassen willst stößt
du sehr schnell an die Grenzen des Möglichen. Da kannst du dann
Kopfstände machen, dass du das hinbekommst. Arduino ist so einfach weil
der Nutzer um viele Einstellungen und Funktionen beschnitten wird.
Einige Dinge fehlen völlig (Debuging, Interrupts, ...). Arduino zeichent
sich im Moment durch die normierte Hardware (mit entsprechenden
Funktionseinbußen) und das Vorhandensein einer vielzahl
funktioniererender Libraries aus. Für gewissen Anwendungsgebiete ist das
genau das richtige ...
Dr. Sommer schrieb:> Einen Ferrari zu fahren ist auch nicht so einfach wie bei einem> Bobby-Car. Aber Ferrari-Fahrer beschweren sich darüber nicht
...und Bobbycarfahrer meist auch nicht...
Harald Wilhelms schrieb:> ...und Bobbycarfahrer meist auch nicht...
Die kennen aber auch den Unterschied zwischen Ferrari und Bobbycar, und
wann das Bobbycar nicht geeignet ist ;-)
Ich sehe schon, hier sind keine Arduino Freunde unterwegs,
Wahrscheinlich kann man auch kein Freund davon sein, sobald man mehr
Ahnung von der Materie hat....
Mich als C Anfänger irritiert jedenfalls diese "Bitschubser Syntax" mit
<< >> usw.
So gern ich auch richtiges AVR C lernen würde, es fehlt mir für meine
kleinen Projekte der Nutzen dafür. Hier reicht bis jetzt die Arduino
Verschwendung aus :)
Je flexibler das System und die sprachlichen Ausdrucksmöglichkeiten,
desto komplizierter.
Je unflexibler und funktionsreduzierter desto einfacher. Zwischen diesen
beiden gegenläufigen Trends gilt es nun den optimalen Schnittpunkt zu
finden- und den kann eigentlich nur die geplante Anwendung diktieren.
Mit mehr Intelligenz in der Hardware lässt sich der freilich in Richtung
höherer Leistungsfähigkeit verschieben.
ArduFAN schrieb:> Ich sehe schon, hier sind keine Arduino Freunde unterwegs,
Nein, das siehst Du falsch.
Ich finde Arduino toll.
Der führt Neulinge an die Thematik heran und bildet eine Brücke zu
Menschen die sonst nie was mit Mikrocontrollern gemacht hätten.
Es ist auch beachtlich was teilweise damit zuwege gebracht wird.
Trotzdem ist das Hobby Heimwerken und meilenweit von den Möglichkeiten
entfernt die man hat wenn man Arduino hinter sich lässt.
Nutzt Du bei Fahradfahren noch immer Deine Stützräder ?
Nicht vorhersagbare Anwortzeiten im ms Bereich mögen Dir wie ein
Geschwindigkeitsrausch vorkommen aber das ist eher das Tempo einer
gehbehinderten Schildkröte.
Arduino ist nicht mehr als ein Chip + Spannungsversorgung + USB /
Seriell Wandler und ein Haufen Software der das nach aussen durch
brachiale Funktionsbeschränkung einfach aussehen lässt.
Der blanke Chip ohne den ganzen Schrott kann viel mehr für weniger Kohle
auf weniger Fläche.
Moby wird jetzt sicher davon anfangen das schon der C Compiler
überflüssig ist und nur Assembler die reine Lehre.
Lehnen wir uns enspannt zurück ...
Michael Knoelke schrieb:> Ich finde Arduino toll.
ich auch, habe aber mit purem AVR am Atmel Studio angefangen
Michael Knoelke schrieb:> Nicht vorhersagbare Anwortzeiten im ms Bereich mögen Dir wie ein> Geschwindigkeitsrausch vorkommen aber das ist eher das Tempo einer> gehbehinderten Schildkröte.
niemand wird gehindert die ISP zu nutzen im AVR Studio
Michael Knoelke schrieb:> Der blanke Chip ohne den ganzen Schrott kann viel mehr für weniger Kohle> auf weniger Fläche.
aber mir macht Quarz, C und anderes Vogelfutter bis hin zum ISP Stecker
auf Lochraster aufbauen und verdrahten keinen Spass mehr wenn es fertige
Module ab 2€ gibt.
Michael Knoelke schrieb:> Moby wird jetzt sicher davon anfangen das schon der C Compiler> überflüssig ist und nur Assembler die reine Lehre.> Lehnen wir uns enspannt zurück ...
und wer hindert einem am Arduino?
ArduFAN schrieb:> Ich sehe schon, hier sind keine Arduino Freunde unterwegs,> Wahrscheinlich kann man auch kein Freund davon sein, sobald man mehr> Ahnung von der Materie hat....
Das ist es eigentlich nicht wirklich.
Die Sache ist eher die, das viele Arduino Programmierer die sich hier
ins Forum verirren, ihre Programmiersprache nur sehr sehr rudimentär
beherrschen. Wenn man das überhaupt so sagen kann. Von dem, was die
Hardware eigentlich hergibt und im Kern funktioniert, reden wir mal gar
nicht.
Solange man in einem Projekt mit den Standardmitteln durchkommt, ist das
auch nicht wirklich ein Problem. Aber wehe wehe, wenn es dann mal
abseits der üblichen Trampelpfade gehen soll. Dann ist oft ganz schnell
Schluss mit lustig. Und das bereits bei eigentlich banalen Sachen.
Es ist halt wie 'Malen nach Zahlen'. Dem einen reicht das, wenn er sich
eine Werkstoffpackung kauft, die Felder anhand von Nummern ausmalt und
sich das Bild an die Wand hängt. Kein Stress mit Bildkomposition, kein
Stress mit Farbenlehre, kein Stress mit Farbenmischen und Palette, kein
Stress den richtigen Pinsel zu benutzen oder die richtige Verdünnung.
Andere wollen eben mehr.
Karl Heinz schrieb:> Solange man in einem Projekt mit den Standardmitteln durchkommt, ist das> auch nicht wirklich ein Problem. Aber wehe wehe, wenn es dann mal> abseits der üblichen Trampelpfade gehen soll. Dann ist oft ganz schnell> Schluss mit lustig. Und das bereits bei eigentlich banalen Sachen.>> Es ist halt wie 'Malen nach Zahlen'. Dem einen reicht das, wenn er sich> eine Werkstoffpackung kauft, die Felder anhand von Nummern ausmalt und> sich das Bild an die Wand hängt.
wer hindert mich einen Arduino mit LIB für ein Touch TFT zu nehmen und
eigene Funktionen in C und/oder ASM dazuzubauen?
Warum soll ich die TFT und Touch Ansteuerung selber machen wenn es LIBs
dafür gibt? (abgesehen mal vom praktischen Shield, aufstecken und läuft)
ArduFAN schrieb:> Mich als C Anfänger irritiert jedenfalls diese "Bitschubser Syntax" mit> << >> usw.
Siehst du, da gehts schon los.
Auch wenn dir digitalWrite diese Bitschubserei in einem speziellen Fall
abnimmt, bleibt aber immer noch der allgemeinere Fall, in dem du
irgendwelche Bitflags anstatt in einem Byte zusammenzufassen und eben
mit dieser Bitschubssyntax anzusprechen dann eben in einzelne Variablen
verteilst. Anstatt von zb 8 Flags in nur 1 Byte unterzubringen benötigst
du 8 Bytes (sofern du nicht das übliche Arduino Problem hast, einfach
überall einen int zu benutzen. Dann sind es schon 16 Bytes). Und so geht
dir dann eben der Speicher schneller aus als demjenigen, der mit den
Bitoperationen auf du-und-du steht.
Solange der Speicher nicht knapp ist, ist das auch kein Problem. Für
nicht benutztes SRAM gibt es kein Geld zurück. Aber wehe, wenn es bei
fortschfreitendem Projekt dann anfängt eng zu werden.
Joachim B. schrieb:> wer hindert mich einen Arduino mit LIB für ein Touch TFT zu nehmen und> eigene Funktionen in C und/oder ASM dazuzubauen?
Niemand.
Aber sei mal ehrlich. Die Mehrheit der Fragesteller mit
Arduino-Hintergrund hier im Forum wäre damit heillos überfordert.
Dass DU das kannst, ist nicht das Thema. Aber du hast ja selbst schon
gesehen, an welch banalen Dingen es oft scheitert.
ArduFAN schrieb:> Mich als C Anfänger irritiert jedenfalls diese "Bitschubser Syntax" mit> << >> usw.
Das liegt rein daran, wie die Includes von Atmel strukturiert sind.
1
#define PORTA7 7
2
#define PORTA6 6
3
#define PORTA5 5
4
#define PORTA4 4
5
#define PORTA3 3
6
#define PORTA2 2
7
#define PORTA1 1
8
#define PORTA0 0
Im normalen Gebrauch halt ich das für ziemlich dämlich weil man eben
ständig mit dem Bit-Geschubse hantieren muss.
Würde das so aussehen:
1
#define PORTA7 128
2
#define PORTA6 64
3
#define PORTA5 32
4
#define PORTA4 16
5
#define PORTA3 8
6
#define PORTA2 4
7
#define PORTA1 2
8
#define PORTA0 1
Könnte man einfach schreiben:
1
PORTA = PORTA0+PORTA4;
2
PORTA = PORTA5|PORTA6;
3
PORTA |= PORTA3;
Nur, so ist es in den vorgegebenen Includes nun einmal nicht definiert.
Man kann sich das problemlos selber definieren:
1
#define POA7 128
2
#define POA6 64
3
#define POA5 32
Nur ist das dann eine reine Insel-Lösung mit der sonst niemand was
anfangen kann.
Also einfach dran gewöhnen und so machen oder auf der eigenen Insel
anders machen, nur mit C an sich hat das mal garnichts zu tun. :-)
Rudolph schrieb:> Nur, so ist es in den vorgegebenen Includes nun einmal nicht definiert.
Dafür gibt es übrigens einen Grund.
Aus der Bitnummer eine Maske zu machen ist trivial
1
#define MASK(x) ( 1 << (x) )
2
3
4
#define BIT0_MASK MASK( PORTA0 )
5
#define BIT1_MASK MASK( PORTA1 )
6
....
aber die Umkehrung ist nicht trivial. Aus einer Maske mit (hoffentlich)
nur einem gesetzten 1 Bit bestimmen, welches Bit das ist.
> Nur, so ist es in den vorgegebenen Includes nun einmal nicht definiert.
Das Schöne an C ist, das man fast nichts als in Stein gemeisselt ansehen
muss.
Wenn mir etwas nicht gefällt, gibt es fast immer Möglichkeiten, wie man
das so hinkriegen kann, wie man es gerne möchte und wie man es als
übersichtlich ansieht.
> Man kann sich das problemlos selber definieren:
Ja. Aber bitte nicht mit Dezimalzahlen. Das ist so ziemlich die dümmste
Schreibweise die du wählen kannst.
> Nur ist das dann eine reine Insel-Lösung mit der sonst niemand was> anfangen kann.
Du unterschätzt die C Programmierer :-)
Gut, einige werden da vielleicht ein wenig stutzig. Aber die Mehrheit
kommt damit durchaus problemlos zurecht. Man kann ja auch durch die Wahl
von vernünftigen Bezeichnern eine kleine Hilfestellung geben.
Joachim B. schrieb:> und wer hindert einem am Arduino?
Niemand.
Ich mach das ja auch so, nur das ich neben der IDE und Processing auch
das Arduino Board weglasse und statt einem urzeitlichen Mega einen xmega
nehme und noch nicht mal mehr einen Quarz brauche.
Entspann Dich, darfst ihn ja weiterverwenden.
Deine 2 Euro toppe ich übrigens mit einem STM8s003 für 30Cent der keinen
Quarz braucht.
Das wird hier aber zum Anpi** Wettbewerb und das ist völlig unnötig,
weil wir schon alle groß sind und jeder seine eigene Entscheidung trifft
was er mag und verwenden will.
Ich denke es ist alles gesagt und ich bin dann raus.
Wer so etwas ähnliches wie Arduino, aber für diverse Controller von TI
haben möchte, der sollte sich Energia ansehen.
Das kann beispielsweise etwas mit dem MSP430'G2-Launchpad und dem darauf
enthaltenen MSP430G2553 anfangen.
Allerdings ist die Dokumentation einiger der mitgelieferten Libraries
mehr als dürftig ... um nicht zu sagen nicht vorhanden (so
beispielsweise "wire", die Library für I2C).
Karl Heinz schrieb:> Dafür gibt es übrigens einen Grund.
Nicht wirklich. Es könnte auch beides definiert sein wobei man die
Bitnummer eher so gut wie nie, die Wertigkeit aber fast immer braucht.
Aber irgendwer hat halt entschieden, dass es schlauer ist eigentlich
überflüssige Zeichenketten immer und immer wieder tippen zu müssen.
Ist eben so.
Rudolph schrieb:> Nicht wirklich. Es könnte auch beides definiert sein wobei man die> Bitnummer eher so gut wie nie, die Wertigkeit aber fast immer braucht.
Komisch. Bei mir ist es genau andersherum. Wenn ich eine 44 sehe und muß
erstmal ausrechnen, daß das die Bits 2, 3 und 5 sind, na danke...
In der "Bitschubser"-Schreibweise steht eindeutig die Bitnummer.
Rudolph schrieb:> Karl Heinz schrieb:>> Dafür gibt es übrigens einen Grund.>> Nicht wirklich. Es könnte auch beides definiert sein wobei man die> Bitnummer eher so gut wie nie, die Wertigkeit aber fast immer braucht.>> Aber irgendwer hat halt entschieden, dass es schlauer ist eigentlich> überflüssige Zeichenketten immer und immer wieder tippen zu müssen.
Müssen?
Mit Verlaub: Nur wenn man schwach in C ist. Dieses 'Problem' ist mit dem
Präprozessor in 5 Sekunden behoben, zumal man im eigentlichen C-Code
sowieso nciht mit den Portbits direkt arbeiten wird, sondern sich dafür
sprechende Makros ausdenkt
1
#define ERROR_LED_MASK ( 1 << PB2 )
2
#define READY_LED_MASK ( 1 << PB5 )
3
4
...
5
6
PORTA&=~READY_LED_MASK;
7
PORTA|=ERROR_LED_MASK;
8
9
MOTOR_PORT=MOTOR_LINKS+LED_LINKS;
d.h. sinnvollerweise wird man sich sowieso die konkrete Pinbezeichnung
hinter einem projektspezifischen Begriff verstecken. Und ob man dann im
#define die Maskenschreibweise oder die Schiebeschreibweise wählt, ist
doch sowas von egal.
ihr tut ja gerade so, als ob das jetzt das Killerkriterium wäre, mit
dem man in jedem Projekt Stunden sinnlose Tipperei vergeudet.
Ja, man hätte in den Header Files auch entsprechende Maskendefinitionen
mit aufnehmen können. Und?
(Ich scheine schon zu alt zu sein. Für jemanden, der es noch gewohnt war
in eine Command Line Kommandos mit 10 Options einzutippen ist es nicht
leicht nachzuvollziehen, warum 12 Tastendrücke mehr beim Schreiben eines
Programms jetzt das grossartige Killerargument sein sollen und warum es
verboten sein soll, sich das selber (igitt) mit dem Präproz zu ändern,
wenn man damit unglücklich ist)
Was ich noch dazu schreiben wollte: Du kannst das doch mit der
"Wertigkeits"-Schreibweise selbst mit wenig Mühe einrichten. Schreib dir
ein Headerfile, wo die Definitionen drin stehen und das kannst du dann
überall einbinden, wo du es brauchst. Ist doch völlig dir überlassen.
Und wenn du jeden Bit einen Namen gibst, kannst du dann sogar schreiben
"PORTA=Karl+Erna+Moritz". Sogar das geht. Also gibt es doch gar keinen
Grund, gegen die sogenannten Bitschubser zu schimpfen. Richtig? :-)
Karl Heinz schrieb:> Ja, man hätte in den Header Files auch entsprechende Maskendefinitionen> mit aufnehmen können. Und?
Denn die tatsächlich sinnvollste Lösung wurde noch überhaupt nicht
angesprochen.
Für jedes Register gibt es eine Bitfeld Struktur, in der die einzelnen
Bits mit ihren Datenblatt-Namen aufgeführt sind.
Das wäre eine saubere Lösung, die noch einen netten Nebeneffekt hat:
Das Problem, das ein Bit im falschen Register angesprochen wird (was zb
bei den Timer-Modi immer wieder mal vorkommt), wäre damit ein für alle
mal gelöst.
Und als Nebeneffekt bürdet man dann auch gleich noch die
unterschiedlichen Operationen für Bit setzen und Bit löschen dem
Compiler auf.
1
PortA.Bit5=1;
und der Compiler soll sich selber was überlegen, wie er das hinkriegt.
npn schrieb:> Komisch.
Nur wenn man nicht verstanden hat, worum es gerade geht.
>In der "Bitschubser"-Schreibweise steht eindeutig die Bitnummer.
Ah ja? (1<<MEINBIT5) sagt was über die Bitnummer?
Der Wert von PORTA7 könnte auch 3 sein, der Gag ist ja gerade, dass es
einen nicht interessieren sollte was da drin steht.
Von einem Controller zum nächsten könnten sich Bits mit gleichem Namen
im gleichen Register auch an unterschiedlicher Position befinden.
Und wie benutzen wir PORTA7?
PORTA = (1<<PORTA7);
PORTA &= ~(1<<PORTA7);
if((PORTA & (1<<PORTA7)) == 0)
Mir fällt gerade nichts ein, wofür ich die Bit-Nummer brauchen würde.
Karl Heinz schrieb:> Müssen?
Ja, natürlich nicht in letzter Konsequenz.
Aber eben doch wenn man nicht für jeden Controller erstmal seine eigenen
Defines schreiben will, sondern verwendet möchte, was die
Entwicklungs-Umgebung vorgibt.
Ich weiss auch nicht, was jetzt das Drama soll, mein Hinweis war
lediglich, dass die "Bitschubser Syntax" kein "Problem" von C ist.
Rudolph schrieb:> Nur wenn man nicht verstanden hat, worum es gerade geht.>>>In der "Bitschubser"-Schreibweise steht eindeutig die Bitnummer.>> Ah ja? (1<<MEINBIT5) sagt was über die Bitnummer?> Der Wert von PORTA7 könnte auch 3 sein, der Gag ist ja gerade, dass es> einen nicht interessieren sollte was da drin steht.
Jetzt dreh mir mal nicht das Wort im Munde herum. Gerade schreibst du
noch:
Rudolph schrieb:> Nicht wirklich. Es könnte auch beides definiert sein wobei man die> Bitnummer eher so gut wie nie, die Wertigkeit aber fast immer braucht.> Ah ja? (1<<MEINBIT5) sagt was über die Bitnummer?
Aber über die Wertigkeit auch nichts.
> Der Wert von PORTA7 könnte auch 3 sein, der Gag ist ja gerade, dass es> einen nicht interessieren sollte was da drin steht.
Eben, und gerade deshalb schrieb ich ja auch:
npn schrieb:> Und wenn du jeden Bit einen Namen gibst, kannst du dann sogar schreiben> "PORTA=Karl+Erna+Moritz". Sogar das geht.
Und Karl Heinz schrieb ja, wie man es problemlos so schreiben kann:
> MOTOR_PORT = MOTOR_LINKS + LED_LINKS;
Das ist doch genau das, was du wolltest. Also höre auf zu schimpfen.
Trink ein Feierabend-Bier lies ein gutes Buch...
Bitschubser schrieb:> if(!(PINA&(1<<7)))>> viel kürzer und funzt sogar
wäre nicht sinnvoller?
if(!(REG&(1<<COM10)))
ob REG nun PORT oder TIMSK ist schnurz
1. interessiert mich nicht in welchem Bit COM10 steckt
2. kann sich das von Prozzi zu Prozzi ändern, der Code bleibt aber
funktionsfähig
Was ich ja bei solchen Diskussionen nicht verstehe: Wenn alle wissen wie
man es besser machen kann, warum bieten diese Leute dann kein Bundle an?
Ist ja das schöne an C, man ist da sehr flexibel.
ArduFAN schrieb:> Ich sehe schon, hier sind keine Arduino Freunde unterwegs,> Wahrscheinlich kann man auch kein Freund davon sein, sobald man mehr> Ahnung von der Materie hat....
Naja, früher glaubten die Deutschen auch,
der "Käfer" wäre das beste Auto der Welt...
Sehe das Arduino Projekt für Einsteiger sinnvoll. Aber sobald man sich
stärker mit der ganze Materie auseinandersetzt, wird man merken, das
nicht alles Gold ist was glänzt ;)
Wenn alle nur die "Arduino-Sprache" beherschen, wer schreibt die Libarys
;) Ich weiß lieber, was ich alles in mein Projekt hineinlade.
Stefan S. schrieb:> Sehe das Arduino Projekt für Einsteiger sinnvoll.
warum nur für Einsteiger?
ich sag immer noch der Arduino und seine Module hindern mich nicht die
anders zu nutzen.
Beispiel? Teile wie Prozessor Platine und Co müsste ich hier teuer
kaufen, die Module gibt es fertig billiger. Schlimmstes Beispiel die
RTC, im örtlichen Handel zahle ich 10€ für den nackten DS3231 Chip, in
China gibt es das Modul mit Chip, Platine, EEPROM und LiR2032 für 1,50€.
Ob ich das am puren Atmel oder Arduino nutze ist doch egal.
ArduFAN schrieb:> Mich als C Anfänger irritiert jedenfalls diese "Bitschubser Syntax" mit> << >> usw.
Wenn das alles ist.
Arduino-like. Code-Länge 2 Bytes. Ausführungsgeschwindigkeit 2 Takte.
z.B. PORTD |= (1 << PB3) = DigitalWrite(19, 1)
1
#define OUTPUT 1
2
#define INPUT 0
3
4
#define SetPortDirection(pin, dir)do\
5
{\
6
if(dir)\
7
{\
8
switch(pin)\
9
{\
10
case 0: DDRB |= (1 << PB0); break;\
11
case 1: DDRB |= (1 << PB1); break;\
12
case 2: DDRB |= (1 << PB2); break;\
13
case 3: DDRB |= (1 << PB3); break;\
14
case 4: DDRB |= (1 << PB4); break;\
15
case 5: DDRB |= (1 << PB5); break;\
16
case 6: DDRB |= (1 << PB6); break;\
17
case 7: DDRB |= (1 << PB7); break;\
18
\
19
case 8: DDRC |= (1 << PC0); break;\
20
case 9: DDRC |= (1 << PC1); break;\
21
case 10: DDRC |= (1 << PC2); break;\
22
case 11: DDRC |= (1 << PC3); break;\
23
case 12: DDRC |= (1 << PC4); break;\
24
case 13: DDRC |= (1 << PC5); break;\
25
case 14: DDRC |= (1 << PC6); break;\
26
case 15: DDRC |= (1 << PC7); break;\
27
\
28
case 16: DDRD |= (1 << PD0); break;\
29
case 17: DDRD |= (1 << PD1); break;\
30
case 18: DDRD |= (1 << PD2); break;\
31
case 19: DDRD |= (1 << PD3); break;\
32
case 20: DDRD |= (1 << PD4); break;\
33
case 21: DDRD |= (1 << PD5); break;\
34
case 22: DDRD |= (1 << PD6); break;\
35
case 23: DDRD |= (1 << PD7); break;\
36
}\
37
}\
38
else\
39
{\
40
switch(pin)\
41
{\
42
case 0: DDRB &= ~(1 << PB0); break;\
43
case 1: DDRB &= ~(1 << PB1); break;\
44
case 2: DDRB &= ~(1 << PB2); break;\
45
case 3: DDRB &= ~(1 << PB3); break;\
46
case 4: DDRB &= ~(1 << PB4); break;\
47
case 5: DDRB &= ~(1 << PB5); break;\
48
case 6: DDRB &= ~(1 << PB6); break;\
49
case 7: DDRB &= ~(1 << PB7); break;\
50
\
51
case 8: DDRC &= ~(1 << PC0); break;\
52
case 9: DDRC &= ~(1 << PC1); break;\
53
case 10: DDRC &= ~(1 << PC2); break;\
54
case 11: DDRC &= ~(1 << PC3); break;\
55
case 12: DDRC &= ~(1 << PC4); break;\
56
case 13: DDRC &= ~(1 << PC5); break;\
57
case 14: DDRC &= ~(1 << PC6); break;\
58
case 15: DDRC &= ~(1 << PC7); break;\
59
\
60
case 16: DDRD &= ~(1 << PD0); break;\
61
case 17: DDRD &= ~(1 << PD1); break;\
62
case 18: DDRD &= ~(1 << PD2); break;\
63
case 19: DDRD &= ~(1 << PD3); break;\
64
case 20: DDRD &= ~(1 << PD4); break;\
65
case 21: DDRD &= ~(1 << PD5); break;\
66
case 22: DDRD &= ~(1 << PD6); break;\
67
case 23: DDRD &= ~(1 << PD7); break;\
68
}\
69
}\
70
}while(0)
71
72
#define DigitalWrite(pin, value)do\
73
{\
74
if(value)\
75
{\
76
switch(pin)\
77
{\
78
case 0: PORTB |= (1 << PB0); break;\
79
case 1: PORTB |= (1 << PB1); break;\
80
case 2: PORTB |= (1 << PB2); break;\
81
case 3: PORTB |= (1 << PB3); break;\
82
case 4: PORTB |= (1 << PB4); break;\
83
case 5: PORTB |= (1 << PB5); break;\
84
case 6: PORTB |= (1 << PB6); break;\
85
case 7: PORTB |= (1 << PB7); break;\
86
\
87
case 8: PORTC |= (1 << PC0); break;\
88
case 9: PORTC |= (1 << PC1); break;\
89
case 10: PORTC |= (1 << PC2); break;\
90
case 11: PORTC |= (1 << PC3); break;\
91
case 12: PORTC |= (1 << PC4); break;\
92
case 13: PORTC |= (1 << PC5); break;\
93
case 14: PORTC |= (1 << PC6); break;\
94
case 15: PORTC |= (1 << PC7); break;\
95
\
96
case 16: PORTD |= (1 << PD0); break;\
97
case 17: PORTD |= (1 << PD1); break;\
98
case 18: PORTD |= (1 << PD2); break;\
99
case 19: PORTD |= (1 << PD3); break;\
100
case 20: PORTD |= (1 << PD4); break;\
101
case 21: PORTD |= (1 << PD5); break;\
102
case 22: PORTD |= (1 << PD6); break;\
103
case 23: PORTD |= (1 << PD7); break;\
104
}\
105
}\
106
else\
107
{\
108
switch(pin)\
109
{\
110
case 0: PORTB &= ~(1 << PB0); break;\
111
case 1: PORTB &= ~(1 << PB1); break;\
112
case 2: PORTB &= ~(1 << PB2); break;\
113
case 3: PORTB &= ~(1 << PB3); break;\
114
case 4: PORTB &= ~(1 << PB4); break;\
115
case 5: PORTB &= ~(1 << PB5); break;\
116
case 6: PORTB &= ~(1 << PB6); break;\
117
case 7: PORTB &= ~(1 << PB7); break;\
118
\
119
case 8: PORTC &= ~(1 << PC0); break;\
120
case 9: PORTC &= ~(1 << PC1); break;\
121
case 10: PORTC &= ~(1 << PC2); break;\
122
case 11: PORTC &= ~(1 << PC3); break;\
123
case 12: PORTC &= ~(1 << PC4); break;\
124
case 13: PORTC &= ~(1 << PC5); break;\
125
case 14: PORTC &= ~(1 << PC6); break;\
126
case 15: PORTC &= ~(1 << PC7); break;\
127
\
128
case 16: PORTD &= ~(1 << PD0); break;\
129
case 17: PORTD &= ~(1 << PD1); break;\
130
case 18: PORTD &= ~(1 << PD2); break;\
131
case 19: PORTD &= ~(1 << PD3); break;\
132
case 20: PORTD &= ~(1 << PD4); break;\
133
case 21: PORTD &= ~(1 << PD5); break;\
134
case 22: PORTD &= ~(1 << PD6); break;\
135
case 23: PORTD &= ~(1 << PD7); break;\
136
}\
137
}\
138
}while(0)
139
140
141
intmain(void)
142
{
143
SetPortDirection(19,OUTPUT);
144
145
while(1)
146
{
147
DigitalWrite(19,1);
148
DigitalWrite(19,0);
149
}
150
}
Wenn man auf seinen Arduino so gar nicht verzichten kann.
mfg.
Ich hab nioch nie verstanden, wieso bei Arduino die Pins nicht einfach
so heissen, wie der Mikrocontroller sie nennt. Diese zusätzliche
Abstraktion ist doch vollkommen wertlos.
Anstatt die Pins von 0-23 zu nummerieren, kann ich doch auch die
"richtigen" Namen gemäß Datenblatt des Mikrocontroller auf die Platine
drucken!
Dann ist auch klarer, welche Pins zusammen gehören und einen Port
bilden.
Stefan us schrieb:> Ich hab nioch nie verstanden, wieso bei Arduino die Pins nicht einfach> so heissen, wie der Mikrocontroller sie nennt. Diese zusätzliche> Abstraktion ist doch vollkommen wertlos.
Nicht ganz. Denn die Nummern finden sich beim ARM-Arduino auch alle
wieder. Auch wenn dort die Ports anders heissen oder die nummerierten
Klemmen in einer ganz anderen Reihenfolge an die Prozessorpins geführt
werden oder überhaupt ganz anders realsiert sind (zb mit einer I/O
Erweiterung über Schieberegister). Mittels
1
digitalWrite(25,HIGH);
geht der Pegel an der mit 25 beschrifteten Klemme auf High. Egal wie die
hardware-Ansteuerung dahinter aussieht.
Im Prinzip hat man hier ein kleines Treiber Konzept, was ja
grundsätzlich nichts schlechtes ist, wenn man den Performance Verlust in
Kauf nehmen kann.
Unangenehm fällt natürlich auf, das ja gerade die Gruppe der Anwender,
an die sich das Arduino-Projekt vornehmlich richtet, also z.B. Künstler
und Leute, die gar keine Ahnung von Elektronik haben(müssen) NATÜRLICH
komplett das Klischee bedienen. Da fällt es schwer, bei der Beantwortnug
etwaiger "Fachfragen" objektiv zu bleiben und nicht "von oben herab" zu
wirken.
Es passt aber auch immer wieder. Der Natur der Sache geschuldet.
Dabei ist die Idee dahinter ja gerade, das Leute, die ihr Kunstwerk nur
mit blinkenden LEDs verschönern wollen, schnell zum Ziel gelangen OHNE
erst C lernen zu müssen. Denen ists auch sch..egal, wie stark die
Performance einbricht, wenn Die LED einen schönen Sonnenuntergang
simulieren soll Beispielsweise.
Das die Masseanschlüsse verschiedener Baugruppen zusammengeschaltet
werden müssen, kann hier nicht oft genug betont werden ;))
Gruß in die Runde
Axelr.
René K. schrieb:> 42 Beiträge und Ctrl-F "cyblord" bringt keine Ergebnisse? Was ist denn> da los?
Der ist über das Carry-Bit hinten raus gewandert.
MfG Paul
Paul Baumann schrieb:> René K. schrieb:>> 42 Beiträge und Ctrl-F "cyblord" bringt keine Ergebnisse? Was ist denn>> da los?>> Der ist über das Carry-Bit hinten raus gewandert.>> MfG Paul
ymmd
Außenstehender:
Dieser Thread ist ein tolles Beispiel dafür, wie gesittet, kompetent und
konstruktiv man sich Themen mit unterschiedlichen Meinungen widmen kann.
Hut ab;-)
Uwe Bonnes schrieb:> kompliziert?
Geht so.
Ich hatte allerdings den springenden Punkt nicht erwähnt. Man möchte
dieselben Header Files auch im avr-Assembler benutzen können. Sind die
Masken-Definitionen in C noch brauchbar, so sieht das in Assembler schon
anders aus, wo man dann die Bitnummer dann auch tatsächlich benötigt.
ArduFAN schrieb:> Deshalb die Frage warum muss man für alles andere einen gefühlt hohen> Aufwand treiben um z.B. nur mal eine LED an einem STM32 µC blinken zu> lassen?
1.
naja nur wenn man etwas gut versteht wird man die Einfachheit dahinter
verstehen und erst recht die Möglichkeiten sehen die ein zur Verfügung
stehen.
2.
Der hohe Aufwand den du beschreibst ist Arduino und wer sich wirklich
mal mit den Datenblättern, egal von welchen Herstellern beschäftigt,
wird sehen das selbst in Assembler die Befehlsätze recht ähnlich sind
und in C braucht man gar nicht drüber reden da hat man schon nen recht
guten Einheitsbrei geschrieben der bei fast gleichbleibenden Text auf
fast jeden µC portierbar ist.
3.
Die jenigen die Arduino programmieren sind auf der 3ten Sprachebene,
wenn man es so will, also noch weiter weg von der Hardwareebene und
diesen Leuten fällt es immer schwerer überhaupt Ansatzweise zum ersten
Punkt zu gelangen weil sie sich recht wenig bis gar nicht mit der
Materie auseinandersetzen wollen/müssen/sollen. Arduino ist vielleicht
nicht verkehrt um einen gewissen Einstieg zu haben, egal in welchem
Alter, die Frage die bleibt "Auf welcher Stufe möchte man stehen bleiben
?" bzw reicht um seine Ziele zu erreichen. Manchmal muss man halt recht
tief gehen damit man das Problem überhaupt versteht um zu einer
einigermaßen zufriedenen Lösung zu kommen....
Tja und dann bleibt da immer noch die Frage
was kompliziert/einfach aussieht, ob es das auch ist oder nicht.
Hallo,
erstmal bin ich erfreut das die ganze Disskusion doch recht entspannt
und fair abläuft (zumindest im Vergleich zu anderen Arduino
Disskusionen).
Ein Vorteil des Arduinokonzepts (bzw. der Gesamtidee mit den umfassenden
Umfeld an Tutorials, Büchern, Videos usw.) ist auch das es Tutorials
gibt die wirklich nichts voraussetzen und sich auf µC Anwendung und
physical computing von Anfang an beziehen.
Leider sieht das bei den anderen Konzepten die auf Programmiersprachen
wie C, Assembler usw. aufbauen fast immer anders aus (leider auch hier
im µC.net Tutorial).
Dort wird "automatisch" davon ausgegangen das bestimmte Konzepte und
Fachbegriffe bekannt sind, oder es wird nur auf Computer (µProzessor)
Ebene gelehrt und kein Bezug auf die Besonderheiten von µC Anwendungen
genommen (Datenbanken, stark formatierte Textausgaben sind bei µC
Anwendungen selten gefragt, und falls doch bestimmt nicht bei Einsteiger
Tutorials).
Auch wenn es "für uns" schwer verständlich ist:
Die Bedeutung von Begriffen wie Variablen, Konstanten, Ganzzahlen,
Integer, Bit, Byte, Word, Implizit, Deklaration usw. gehören nicht zur
Allgemeinbildung bzw. werden erst einmal von vielen falsch/anders
verstanden. Leider wird das aber bei den übergroßen Teil der
Programmiertutorials (ohne böse Absicht) vorausgestzt das sowas bekannt
ist und besonders bei Publikationen (egal ob Online oder als Buch) die
sich nicht in erster Linie an Hobbyanwender richten, wird (scheinbar)
besonders viel Wert gelegt sich möglichst unverständlich, umständlich
und irgendwie "abgehoben" aus zu drücken.
Und genau in dieser Lücke passt dass ganze umfassende Adruino Konzept.
Wenn es jemand fertig bringen würde C, Assembler usw. ähnlich
Anfängertauglich und direkt mit µC Bezug (z.B. AVR) zu lehren, wäre
sowas wie Adruino (als Gesamtsystem, nicht jetzt das Board als Hardware
selber) mit seinen gegebenen Einschräkungen und der Gefahr zu
Oberflächlich zu lehrnen nicht notwendig.
mfg
AVRler
AVRler schrieb:> Wenn es jemand fertig bringen würde C, Assembler usw. ähnlich> Anfängertauglich und direkt mit µC Bezug (z.B. AVR) zu lehren
Das kann niemand "fertigbringen", weil diese Sprachen nun mal komplexer
sind dank ihres viel feinkörnigeren, flexibleren, detaillierteren
Zugangs zu jedem einzelnen Bit der Hardware (das es folglich auch zu
kennen gilt). Mit den heutigen Controllern ist reale Vereinfachung der
Programmierung nur auf Kosten abstrahierender, leistungsfressender
Software möglich -> siehe eben Arduino. Damit ist ausdrücklich nicht
jene Art der "Vereinfachung" gemeint, die manche durch (wieder auf
andere Art verkomplizierende) Hochsprachenprogrammierung a la C++ und
OOP zu erreichen versuchen ;-)
Stefan us schrieb:> Ich hab nioch nie verstanden, wieso bei Arduino die Pins nicht> einfach> so heissen, wie der Mikrocontroller sie nennt. Diese zusätzliche> Abstraktion ist doch vollkommen wertlos.
Mitnichten. Das soll und muß so sein. Geht es doch gerade darum Details,
die für die Anwendung (z.B. einfache Digital-IO) völlig bedeutungslos
sind zu verbergen. Die beste Vereinfachung wäre freilich Hardware, bei
der jeder IO-Pin tatsächlich auch jede Hardwarefunktion ausführen kann.
AVRler schrieb:> Dort wird "automatisch" davon ausgegangen das bestimmte Konzepte und> Fachbegriffe bekannt sind>...
Das ist aber, meiner Meinung nach, eine Grundvoraussetzung für jede
Programmiersprache. Man muss wissen was Variablen und Co sind und wenn
ich das mal nicht weiß muss ich mir das bei bringen.
Ich kenne Arduino nur vom Namen her, finde das Konzept dahinter
eigentlich auch gut soweit ich es mir bisher angeschaut habe aber ich
kann mir nicht vorstellen, dass ich da nicht wissen muss was eine
Variable ist, was PWM bedeutet usw. Da kommt man meiner Meinung nach bei
keiner Programmiersprache/µC-Entwicklung drum rum sich das beizubringen
wenn man es noch nicht weiß.
Ist ähnlich wie mit dem Schreiben: Ich muss nicht wissen wie ein
Bleistift intern aufgebaut ist, ich muss aber schon wissen was der
Unterschied zwischen einem Buchstaben, einer Zahl und einem Satzzeichen
ist.
Moby schrieb:> Die beste Vereinfachung wäre freilich Hardware, bei> der jeder IO-Pin tatsächlich auch jede Hardwarefunktion ausführen kann.
Für den Programmierer, für die Hardware würde das enormen Mehraufwand
bedeuten. Und wozu das Ganze? Damit der Programmierer nicht mehr groß
lesen muss? Das ist Meiner Meinung nach wenig sinnvoll.
Michael Köhler schrieb:> Ist ähnlich wie mit dem Schreiben: Ich muss nicht wissen wie ein> Bleistift intern aufgebaut ist,
wäre das nicht sinnvoll wenn man dokumentenecht eine Unterschrift
leisten will?
Joachim B. schrieb:> wäre das nicht sinnvoll wenn man dokumentenecht eine Unterschrift> leisten will?
Sinvoll ja aber, ich muss in diesem Fall nur wissen ob der Bleistift die
Eigenschaft "Dokumentenecht" erfüllt. Die Kenntniss wie der Bleistift
intern aufgebaut ist sagt mir vielleicht auch ob er die Eigenschaft
erfüllt, richtig. Wenn ich aber weiß, dass der Bleistift die Eigenschaft
erfüllt oder auch nicht erfüllt brauche ich schlicht keine weitere
Information über seinen internen Aufbau.
Hi,
vll. Sollte man zuerst die Grundlagen von der Auserwählten
Programmiersprache (ich schließe jetzt mal Assembler aus) können. Diese
lernt man recht einfach am PC (weil ich GLAUBE das Assembler tatsächlich
leichter auf einem 8Biter zulernen ist), man muss sich nicht (oder kaum)
um den Speicherverbrauch kümmern, hat einen gescheiten Debugger zur
Hand.
Wenn man nun die Grundlagen kann man auf die µC gehen, da sind es zwar
andere Aufgaben, aber neue Hardware + neue Programmiersprache (am besten
noch nie Programmiert hat) sind halt 2 Schritte auf einmal. Oder wie
mein Vater sagen würde: Noch net grad aus pinkeln können, aber um die
Kurve probieren.
MfG
ich
> Wenn es jemand fertig bringen würde C ... ähnlich> Anfängertauglich und direkt mit µC Bezug (z.B. AVR) zu lehren,> wäre sowas wie Adruino... nicht notwendig.
Ich habe mich bemüht, so ein Tutorial zu schreiben. Vielleicht ist es
mir ja tatsächlich gelungen. Leider erhalte ich dazu fast gar kein
Feedback, obwohl der Webserver über 1000 Downloads pro Monat
registriert.
http://stefanfrings.de/mikrocontroller_buch/index.html
Die Frage des Freds "Warum nicht alles so einfach wie A...." nehme ich
als Anlass für die Frage desjenigen, welcher noch keine Erfahrung mit
Arduino und C hat. Die Frage: Sehe ich das richtig, dass die
Prog.-Sprache für einen Arduino ein fast normales C ist, bei dem "nur"
am Anfang, bei der Initialisierungsroutine für den indiv. MC-Prozessor
eingespart wurde?
Gruß, wilhelmT
Be Ti schrieb:> Die Frage: Sehe ich das richtig, dass die> Prog.-Sprache für einen Arduino ein fast normales C ist, bei dem "nur"> am Anfang, bei der Initialisierungsroutine für den indiv. MC-Prozessor> eingespart wurde?
nicht wirklich
normales C würde ich mit ja beantworten
Initialisierungsroutine eher mit jain oder kommt drauf an
wenn ich ohne Timer arbeite muss ich nix initialisieren, kann gleich
losarbeiten
ob ich nun in Arduino
pinMode(ledPin, OUTPUT); mache
wäre initialisieren genau wie am AVR
DDRn |= (1<<ledPin);
setze ich die LED auf on in Arduino
digitalWrite(ledPin, HIGH);
ist es in AVR Sprache
PORTn |= (1<<ledPin);
man kann es so oder so machen, für eine LED sind 2 Anweisungen nötig, ob
in der Arduino IDE oder im AVR Studio
Joachim B. schrieb:> nicht wirklich> normales C würde ich mit ja beantworten> Initialisierungsroutine eher mit jain oder kommt drauf an
War wohl ein Verständnis- oder Formulierungsfehler von mir. Ich hatte
das so verstanden, dass in der Arduino-Sprache diese ganzen Anpassungen
und Zuordnungen nicht notwendig sind, welche bei Assembler oder wohl
auch in C am Prog-Anfang mühsam aus dem Datenblatt rausgelesen werden
müssen.
> ob ich nun in Arduino> pinMode(ledPin, OUTPUT); mache>> wäre initialisieren genau wie am AVR> DDRn |= (1<<ledPin);
Was mich als C-Unkundiger u.a. so schreckt, sind die furchtbar vielen
Sonderzeichen.
Gruß, wilhelmT
Be Ti schrieb:> Was mich als C-Unkundiger u.a. so schreckt, sind die furchtbar vielen> Sonderzeichen.
Mich auch.
Auf die Gefahr hin, gleich mit Nudelholz und Schaffen Eine übergebraten
zu kriegen: Du kannst auch mit Bascom auf dem Arduino herumfuhrwerken.
Da ist die Syntax der Sprache besser lesbar.
MfG Paul
Paul Baumann schrieb:> gleich mit Nudelholz und Schaffen Eine übergebraten> zu kriegen
ach wer macht denn sowas?
Paul Baumann schrieb:> mit Bascom auf dem Arduino herumfuhrwerken.> Da ist die Syntax der Sprache besser lesbar
na ja, ich hatte auch mit BASCOM am puren AVR angefangen ist leicht
bringt einen aber später nicht viel weiter, zum Einstig OK auf C
umzuschwenken notfalls auch mit dem kleinen Umweg über die Aruino IDE
ist kein Fehler wenn die ersten Dinge laufen.
Hallo,
Michael Köhler schrieb:
"Das ist aber, meiner Meinung nach, eine Grundvoraussetzung für jede
Programmiersprache. Man muss wissen was Variablen und Co sind und wenn
ich das mal nicht weiß muss ich mir das bei bringen."
Ja natürlich, da hast du vollkommen recht - es ist bei Adruino (viel
mehr als bei anderen Konzepten bzw. Programmiersprachen) aber
tatsächlich so das sehr viele Tutorials,Videos, Bücher, etc. es so
erklären das es auch absolute Anfänger ohne jeglich Vorkenntnisse
verstehen können (natürlich nicht auf einer Seite - auch bei Arduino muß
man Durchhaltevermögen haben und z.B. ein Buch von 300 und mehr Seiten
durcharbeiten).
Ich selber habe mir die ersten Programmierkenntnisse (C) über viele
verschiedene Quellen beigebracht da es nur sehr wenige (deutschsprachige
oder in "einfachen" Englisch) Quellen gibt welche sich tatsächlich
umfassend an unbedarfte Anfänger richten.
Das besondere am Konzept Arduino besteht nicht aus dem Board und der IDE
sondern aus einer großen Gemeinschaft die aus vielen Leuten mit
unterschiedlichsten Interessen und Vorwissen besteht - wo aber auch die
"Profis" wissen das sie auch unbedarfte Anfänger mit ansprechen und
dementsprechend entweder alles "Klein Klein" erklären , oder Verweise
geben wo man nachsehen kann bzw. was noch gelehrnt werden sollte.
mfg
AVRler
Be Ti schrieb:> Joachim B. schrieb:> …> Was mich als C-Unkundiger u.a. so schreckt, sind die furchtbar vielen> Sonderzeichen.> Gruß, wilhelmT
o
Welche Sonderzeichen? Etwa | oder << und co? Das ist doch
Standardzeichensatz der zu Beginn eines jeden Einsteigerbuches für C
erklärt wird...
Blackbird schrieb:> Die Sprache ist doch (fast) egal - Programmieren muss man können.
Na super, jetzt weiß ich, was zu tun ist.
Dieser Fred beinhaltet die Sorgen von Anfängern vor Hochsprachen. Da hat
wohl "AVRler" den richtigen Punkt getroffen mit seiner Aussage:"Das
besondere am Konzept Arduino besteht nicht aus dem Board und der IDE
sondern aus einer großen Gemeinschaft".
Gruß, wilhelmT
Blackbird schrieb:> Die Sprache ist doch (fast) egal - Programmieren muss man können.
Das ist gut gesagt, aber:
Man hat eine Aufageb, setzt sich hin und entwirft den Algorithmus, um
die
Aufgabe zu lösen auf Papier. (So mache ich es)
Dann sieht man, welche Variablen in welcher Zahl und Art man braucht.
Das war die einfachere Teilaufgabe...
Und jetzt geht der SPASS los:
Wie sag ich's meinem Kompiler?
Das ist das eigentliche Problem -die Suche nach der richtigen Syntax,
die Suche nach im DATENBUCH (nein, nicht Datenblatt bei > 300 Seiten!)
nach dem Versteck der für die jeweilige Funktion zu setzenden Bits
u.s.w.
DAS ist das ZEITRAUBENDE und vor Allem FEHLERTRÄCHTIGE, nicht das
Programmieren an sich, denn darunter verstehe ich NUR das Finden der
richtigen Vorgehensweise.
MfG Paul
Thomas Eckmann schrieb:> Wenn man auf seinen Arduino so gar nicht verzichten kann.
Thomas, das war nicht nur sehr lustig, sondern auch besonders
anschaulich für "die Arduino User".
Mein Einstieg war Arduino und sicher hätte ich alles hin geschmissen,
wenn ich nicht damit angefangen hätte.
Dass ich keinen ganzen Port ansprechen konnte (das dachte ich, weil in
keinem Buch ein Hinweis darauf war) und das in C so einfach ging, das
war für mich der Grund dieses Arduino zu verlassen.
Auch die IDE fand ich gut und einfach - anfangs.
Anfangs verstand ich auch Cyblord nicht, ganz einfach, weil ich zu wenig
wusste.
Auch funktionierte ein DS18B20 nicht bei mir wie er sollte. Das lag aber
daran, dass es DS18S20 waren und ich aber immer von "B" ausgegangen war.
Nach dem ich mit OneWire einigermaßen klar kam, hätte ich mir die lib
dazu anpassen müssen, die ist aber in C geschrieben.
So dachte ich, wenn ich doch C lernen muss, dann kann ich auch gleich
alles in C machen.
Ich tue mich immer noch schwer damit, weil ich zwischendurch immer
wieder große Lücken im Programmieren habe und ja auch noch viel über
Bauteile und Schaltungen lernen muss und dadurch eigentlich fast immer
von vorne anfangen muss.
Aber gerade durch deine so "bildliche" Darstellung muss jedem Arduino
Programmierer klar werden, was nötig ist diesen Pin so zu bezeichnen.
Und dann noch was: Arduino muss man auch erst lernen.
Thread beobachten
Seitenaufteilung abschalten