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
Einen Ferrari zu fahren ist auch nicht so einfach wie bei einem Bobby-Car. Aber Ferrari-Fahrer beschweren sich darüber nicht
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!
Einiges ist ausgespart, vor allem Interrupts. In den Unterlagen zum Arduino ist der Begriff fast nicht zu finden.
es ist einfach aber es gibt auch Schatten, mit mehreren LIBs oder SW Modulen zu arbeiten wie im Studio ist grausam und nervig. ich habe nur die Wahl zwischen m328p und mega2560, ich will aber einen m1284p und habe mir deswengen Platinen geordert The Mighty Mini 1284P https://github.com/JChristensen/mini1284 gibt noch mehr die diesen Weg gehen: http://www.intorobotics.com/open-source-mini-duino-provide-features-fun-arduino/ http://maniacbug.wordpress.com/2011/11/27/arduino-on-atmega1284p-4/ http://www.crossroadsfencing.com/BobuinoRev17/
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 ;-)
Es soll auch arduino auf pic32 geben Und auf stm32. Einfach mal suchen wie diese arduino IDE heissen.
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.
:
Bearbeitet durch User
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)
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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)
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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...
Rudolph schrieb: > if((PORTA & (1<<PORTA7)) == 0) Guck mal:
1 | if(!(PINA&(1<<7))) |
viel kürzer und funzt sogar
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.
Karl Heinz schrieb: ... > 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 | > .... |
7 | >
|
> > aber die Umkehrung ist nicht trivial. Aus einer Maske mit (hoffentlich) > nur einem gesetzten 1 Bit bestimmen, welches Bit das ist. > Was ist an #define _BI2(arg) (((arg) & 0x00000002) ? 1: 0) #define _BI4(arg) (((arg) & 0x0000000c) ? ( _BI2(arg>> 2) + 2) :\ _BI2(arg)) #define _BI8(arg) (((arg) & 0x000000f0) ? ( _BI4(arg>> 4) + 4) :\ _BI4(arg)) #define _BI16(arg) (((arg) & 0x0000ff00) ? ( _BI8(arg>> 8) + 8) :\ _BI8(arg)) #if defined __builtin_clz #define _BI32(arg) (31 - __builtin_clz(arg)) #else #define _BI32(arg) (((arg) & 0xffff0000) ? (_BI16(arg>>16) + 16) :\ _BI16(arg)) #endif kompliziert?
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.
:
Bearbeitet durch User
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 | int main(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.
42 Beiträge und Ctrl-F "cyblord" bringt keine Ergebnisse? Was ist denn da los?
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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...
Die Sprache ist doch (fast) egal - Programmieren muss man können. Blackbird
Wie jetzt, der Thread ist schon über einen Tag alt und hat bei der Überschrift noch keine 200 Beiträge? Seit ihr müde geworden?
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 abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.