@ Karl Käfer (Gast) >es nicht um eine Vollkaskomentalität, sondern um Motivation. Gut. >Wenn Du jemanden, der das als Hobby machen will, gleich zu Beginn mit >etlichen Fehlschlägen (und dann auch noch mit "hilfreichen" Kommentaren >wie "selbst schuld" und "lern C") verprellst, dann schmeißt der das Zeug >irgendwann in die Ecke. Ja. > Ist es das, was Du erreichen willst? NEIN! > Denn dann wären wir ganz schnell wieder bei der Sache mit dem > Herrschaftswissen. Ja. >Auch mit Arduino machen die Leute genügend negative Erfahrungen, wie die >vielen Arduino-Postings hier im Forum doch ziemlich eindeutig belegen. Mag sein. Ich bin auch kein Gegner von Arduino! Ich finde den Ansatz schon sehr gut! Und Arduino kann man, das entsprechende Wissen vorausgesetz, auch deutlich perfomanter programmieren. Alles kein Problem. Anfänger sind Anfänger, und die dürfe auch erstmal klein und mit wenig Power anfangen, auch mit unvollständigem Wissen, Delay statt Timer. Der Rest ergibt sich. Wer dann WIRKLICH besser werden will um mehr zu können, der entwickelt sich. Wer das nicht will, bleibt halt beim Anfängerniveau stehen. Ist OK. Kein Lernprozess ist perfekt. Ich habe auch ne Weile gebraucht, um von meinem mittelmässigem Spaghetticode mit BASIC auf etwas solidere Strukturen in Pascal umzusteigen. Anfangs hielt ich es für UNMÖGLICH, ohne Goto ein Programm zu schreiben ;-) >Ja, das Fachwort dazu lautet "Risikokompensation" und ist nicht nur in >der IT-Sicherheit ein ebenso ständiges wie leidiges Thema. Danke für das Stichwort. http://de.wikipedia.org/wiki/Risikokompensation
Matthias H. schrieb: > SE schrieb: >> Problem ist nur das die generell auf 5V laufen und oft (oder immer?) mit >> 16Mhz. > > Stimmt beides nicht, einige arbeiten mit 3,3 V (z. B. Due) und es gibt > auch welche mit abweichender (allerdings vorgegebener) Taktfrequenz (z. > B. Fio, 3,3 V und 8 MHz). Ich habe gerade einen SainSmart Uno R3 erstanden, der hat einen Umschalter für 5V und 3,3V. Zusätzlich sind, da M328P TQPF, PC6 und 7 auch herausgeführt.
Quack schrieb: > Aber eine Frage konnte der Thread wenigstens beantworten: Ja, Arduino > ist hier verpoent. Sehe ich nicht so. Leute, die einen professionellen Hintergrund vermuten lassen, sind da emotionslos. Sicher gibt es da auch Vorlieben aber Zeit ist eben Geld. Die Abwägung, zu was ich was nehmen sollte, bedingt einen größeren Horizont, den ich den Eindimensionalen nicht abnehmen kann. Die hört man leider nur mit ihren markanten Worten am lautesten.
Kropf schrieb: > Die hört man leider nur mit ihren markanten Worten am lautesten. Da von den wenigen Lauten aber jeder Arduino-thread geentert wird, kommt am Ende das Gleiche raus, als haetten Alle ein Problem mit Arduinos.
Hier ein heute erschienener Artikel der dieses Thema behandelt: Embedded-Programmierung im Umbruch Aufgrund langer Produktzyklen und hoher Fehlschlagrisiken erweist sich der Embedded-Bereich als vergleichsweise innovationsscheu. Doch gilt auch hier, dass die Zeit des Zählens von Bits so langsam vorbei ist. Das liegt auch an Systemen wie Arduino und Raspberry Pi, die einen einfacheren Einstieg in Embedded ermöglichen. http://www.heise.de/developer/artikel/Embedded-Programmierung-im-Umbruch-2082301.html
KlausImHaus schrieb: > Hier ein heute erschienener Artikel der dieses Thema behandelt: > > Embedded-Programmierung im Umbruch > > Aufgrund langer Produktzyklen und hoher Fehlschlagrisiken erweist sich > der Embedded-Bereich als vergleichsweise innovationsscheu. Doch gilt > auch hier, dass die Zeit des Zählens von Bits so langsam vorbei ist. Das > liegt auch an Systemen wie Arduino und Raspberry Pi, die einen > einfacheren Einstieg in Embedded ermöglichen. > > http://www.heise.de/developer/artikel/Embedded-Programmierung-im-Umbruch-2082301.html Schöner Artikel. Selten eine gequirltere Kacke gelesen. mfg.
Das Thema ist äquivalent zu den Controller Djs vs. Turntable Djs. Bei den Controllern muss man auch kein Beatmatching beherschen, das macht alles die Software...
KlausImHaus schrieb: > Dachte mir schon das es einigen gefallen wird :D Sehr guter Artikel, trifft meine Meinung zu dem Thema auch. Am besten gefällt mir der Satz: "Die von Banzi vertretene Sicht der Dinge ist genauso falsch wie die des pensionierten Managers. Der beste Weg liegt, wie so oft, in der Mitte." Für Spielzeug à la "Kaffeemaschine einschalten" ist ein Arduino allemal gut genug. Die Schnellabschaltung einer Kreissäge sollte man aber dann doch so Takt-Sparend wie möglich realisieren. M•E•I•N•E M•E•I•N•U•N•G
Michael schrieb: > KlausImHaus schrieb: >> Dachte mir schon das es einigen gefallen wird :D > > Sehr guter Artikel, trifft meine Meinung zu dem Thema auch. > Am besten gefällt mir der Satz: "Die von Banzi vertretene Sicht der > Dinge ist genauso falsch wie die des pensionierten Managers. Der beste > Weg liegt, wie so oft, in der Mitte." > > Für Spielzeug à la "Kaffeemaschine einschalten" ist ein Arduino allemal > gut genug. > Die Schnellabschaltung einer Kreissäge sollte man aber dann doch so > Takt-Sparend wie möglich realisieren. > > M•E•I•N•E M•E•I•N•U•N•G Ja, gut genug ist er. Aber vollkommen überdimensioniert...
zong schrieb: > Michael schrieb: >> KlausImHaus schrieb: >>> Dachte mir schon das es einigen gefallen wird :D >> >> Sehr guter Artikel, trifft meine Meinung zu dem Thema auch. >> Am besten gefällt mir der Satz: "Die von Banzi vertretene Sicht der >> Dinge ist genauso falsch wie die des pensionierten Managers. Der beste >> Weg liegt, wie so oft, in der Mitte." >> >> Für Spielzeug à la "Kaffeemaschine einschalten" ist ein Arduino allemal >> gut genug. >> Die Schnellabschaltung einer Kreissäge sollte man aber dann doch so >> Takt-Sparend wie möglich realisieren. >> >> M•E•I•N•E M•E•I•N•U•N•G > > Ja, gut genug ist er. Aber vollkommen überdimensioniert... Wenn du morgen einkaufen gehst, dann beobachte mal mit was für Autos der "Durchschnittsdeutsche" im Supermarkt vorfährt. Mein Lieblingsmodell ist der Geländewagen "Pajero" (kann jemand Spanisch ;-) ) Im Ernst: Natürlich ist es überdimensioniert für so etwas. Aber deshalb ist es auch eine individuelle Lösung für den Arduino-Hobby-Bastler. Wollte jemand das Produkt in Massen anbieten, dann ist ein Arduino selbstverständlich nicht mehr die erste Wahl.
In der Welt alles Lebenden gibt es immer zwei maßgende Faktoren: - Aufwand - Nutzen Diese beiden Faktoren haben die Evolution seit Jahrmillionen geprägt und auch im technischen Bereich gelten diese fundamentalen Regeln. Zunächst gilt es zu definieren was unter "Aufwand" zu verstehen ist. Nun - Der Aufwand lässt sich in stoffliche und nichtstoffliche Aspekte gliedern. Es gibt den materiellen Aufwand (häufig monetär quantifiziert) und den zeitlichen Aufwand. Der Arduino-Nutzer ist bestrebt einen bestimmten Nutzen zu erzielen (Das funktionierende Gerät). Ferner führt der Arduino-Nutzer eine Priorisierung jener zwei Aspekte durch, welche wir als "materiellen" und "zeitlichen" Aufwand bezeichnet haben. In der Regel wird der Arduino-Nutzer wohl den zeitlichen Aufwand höher priorisieren als den materiellen Aufwand (Geld). Ihm kommt es nicht darauf an, ob das Gerät (in der Regel ein Einzelstück) einige Euro mehr oder weniger kostet. Er wird also versuchen das Ziel möglichst Schnell zu erreichen. Die Geschwindigkeit der Entwicklung korreliert hierbei mit der Abstraktionshöhe des genutzen Systems. Da Arduino einen hohen Abstraktionsgrad zur Verfügung stellt, passt dieses System gut auf das Anforderungsprofil des typischen Arduino-Nutzers (niedriger Kenntnissstand).
@ KlausImHaus (Gast) >http://www.heise.de/developer/artikel/Embedded-Pro... Durchwachsen. >Aufgrund langer Produktzyklen und hoher Fehlschlagrisiken erweist sich der >Embedded-Bereich als vergleichsweise innovationsscheu. Beweis? Wir heute überall noch wie vor 10 oder gar 20 Jahren entwickelt? Kaum. > Dank diverser Hochsprachen seien nun auch Künstler, Grafiker und >Architekten zum Konstruieren von Gadgetry befähigt – und das ohne >langwieriges Studium der internen Architektur des verwendeten >AVR-Controllers. Stimmt. Und das ist auch eine große Leistung der Plattform. > Von Seiten des Managers kam daraufhin der Einwand, dass die damit >erstellten Produkte aus technischer Sicht nur mangelhaft sein könnten – Nein. >wer die interne Architektur der zugrunde liegenden MCU (Microcontroller >Unit) nicht verstehe, erstelle keine effizienten Applikationen. Effizient genug, um den anvisierten Zweck unter Beachtung der eigenen Fähigkeiten zu erfüllen. > Die verschwindend geringe Minderheit fokussierte ihre Kritik vor allem >an der als Entwicklungsumgebung verwendeten Sprache Processing. Diese ist >alles andere als hardwarenah, der aus der Hochsprache generierte >Assembler-Code lässt sich nicht ohne Weiteres nachvollziehen. Das muss er auch gar nicht. Wozu? >Aufgrund der eher geringen Rechenleistung und des einfachen Aufbaus ist >der Einsatz von Hochsprachen aus technischer Sicht alles andere als >sinnvoll. Zudem "übt" das Programmieren in Assembler das Gehirn der >Entwickler. So ein Käse. >Ein kleiner Teil der Kritiker ging aus diesem Grund sogar so weit, Banzi >vorzuwerfen, dass er dafür verantwortlich wäre, dass die nachkommenden >Programmierer zunehmend weniger "praktische Erfahrung" mitbrächten. Käse die 2. > Die Mehrheit der Anwesenden ging jedoch davon aus, dass die Kreativität >der Nutzer wichtiger sei als die technische Effizienz des resultierenden >Systems. Ist auch so. Es sind eher Nutzer, nicht Entwickler. So etwa wie die Leute, die ne handvoll Formeln ins Excel tippen, bei Visual basic Macros aber abwinken. >Dabei handelt es sich – zumindest bis zu einem gewissen Grad – um eine >logische Abwehrreaktion, die die Verteidigung der eigenen Pfründe >avisiert. Solange das Entwerfen von Embedded-Steuerungen eine >komplizierte Aufgabe darstellt, lässt sich mit Beratungsdienstleistungen >viel Geld verdienen. Unsinn. Mit RICHTIGER Entwicklung wird auch noch Geld verdient, denn dort braucht man "etwas" mehr Know How als bisse Arduino. Der Gadget-Bereich darf ruhig von den Arduinos "übernommen" werden. > Der Einsatz programmierbarer Suchköpfe könnte im Rüstungsbereich zu > einem Quantensprung führen Hier sollte der Autor mal was zum Thema Netiquette lesen. Keine Sau weiß, wovon er redet. >Bei einem für die Massenfertigung vorgesehenen Produkt ergibt das >Einsparen einiger Cents an Hardwarekosten Sinn. In diesem Fall wäre die >Verwendung von Assembler und einem "kleinen" Controller mit Sicherheit >gerechtfertigt Ja. Aber selbst hier ist heute oft C vollkommen ausreichend und die EInsparung duch ASM ziemlich gering. > – für ein in Kleinserie produziertes System sieht die Kalkulation >naturgemäß völlig anders aus. Eben. > Doch gilt auch hier, >dass die Zeit des Zählens von Bits so langsam >vorbei ist. Ja, und das ist auch OK. >Einplatinen-Computer wie Arduino, Raspberry Pi und BeagleBone bieten >Rechenleistungen, die vor zehn Jahren im Workstation-Bereich üblich waren. Stimmt. Aber was wird draus gemacht? Ein LED-Blinker mit Webserver? Ohje. > Das liegt auch an Systemen wie Arduino und Raspberry Pi, die einen >einfacheren Einstieg in Embedded ermöglichen. Einstieg vielleicht, aber dadurch wird man sicher nicht im Handumdrehen zum Experten, der die CPU mal WIRKLICH fliegen lässt. Die ganzen Arduino und Raspberry Pi Experten verbrennen meist viel Power für kleine Aufgaben. Für ein paar Test, Spielereien, Gadgets und Hobby ist das OK, wenn es aber mal um erstere, wirklich LEISTUNGSHUNGRIGE Dinge geht, ist schnell das Ende der Fahnenstange erreicht.
aus dem Heise-Artikel: "Eine technisch nicht sonderlich begabte Lebensgefährtin eines Elektronikers nutzte einen Arduino, um ihre Kaffeemaschine vom Bett aus fernsteuern zu können" eine Funksteckdose gibts aber bei Pollin fix und fertig deutlich billiger
>> "Eine technisch nicht sonderlich begabte Lebensgefährtin eines >> Elektronikers nutzte einen Arduino, um ihre Kaffeemaschine vom Bett aus >> fernsteuern zu können" > eine Funksteckdose gibts aber bei Pollin fix und fertig deutlich > billiger Genau! "All you can eat" beim Chinesen ist auch schnell und billig. Dennoch meinen manche sie könnte es besser und kochen selbst. Allein die Kosten für die Küche! Das lohnt doch alles nicht...
>Für Spielzeug à la "Kaffeemaschine einschalten" ist ein Arduino allemal >gut genug. >Die Schnellabschaltung einer Kreissäge sollte man aber dann doch so >Takt-Sparend wie möglich realisieren. Was die Reaktionszeiten in der Mechanik angeht, täuschen sich die meisten. Selbst die Air-Bag Auslößung wird im Millisekundenbereich abgehandelt. Mikrosekunden spielen da keine Rolle.
Hier die Größenordnungen für den Airbag: http://www.shortnews.de/id/186044/bosch-und-das-airbag-tuning
Walter schrieb: > aus dem Heise-Artikel: > "Eine technisch nicht sonderlich begabte Lebensgefährtin eines > Elektronikers nutzte einen Arduino, um ihre Kaffeemaschine vom Bett aus > fernsteuern zu können" > > eine Funksteckdose gibts aber bei Pollin fix und fertig deutlich > billiger Völlig richtig. Lasst es gut sein. In dem Artikel werden Äpfel mit Birnen durcheinander geworfen. Schade, dass der Autor das nicht behirrnt hat. Besagte Dame kann auch mit ihrem Nagellack die kleine Schramme am Auto kaschieren. Das macht sie aber noch lange nicht zum ausgebildeten Lackierer.
Feinschmecker schrieb: >>> "Eine technisch nicht sonderlich begabte Lebensgefährtin eines >>> Elektronikers nutzte einen Arduino, um ihre Kaffeemaschine vom Bett aus >>> fernsteuern zu können" > >> eine Funksteckdose gibts aber bei Pollin fix und fertig deutlich >> billiger > > Genau! "All you can eat" beim Chinesen ist auch schnell und billig. > Dennoch meinen manche sie könnte es besser und kochen selbst. Allein die > Kosten für die Küche! Das lohnt doch alles nicht... im Artikel geht es dann so weiter: "Ihr Leben wurde somit um ein technisches Gerät reicher, das sie sonst nicht (oder nur mit viel Aufwand) hätte erhalten können." deshalb noch Mal: das gibts anderwo billiger (und vermutlich sogar den Sicherheitsvorschriften genügend)
Walter schrieb: > aus dem Heise-Artikel: > "Eine technisch nicht sonderlich begabte Lebensgefährtin eines > Elektronikers nutzte einen Arduino, um ihre Kaffeemaschine vom Bett aus > fernsteuern zu können" Du glaubst doch nicht ernsthaft, daß das wahr ist? mfg.
Karl Heinz schrieb: > Besagte Dame kann auch mit ihrem Nagellack die kleine Schramme am Auto > kaschieren. Das macht sie aber noch lange nicht zum ausgebildeten > Lackierer. Wenn du ein IKEA-Regal kaufst und es selbst aufbaust, macht dich das nicht zu einem Schreiner. Wenn du in deiner Küche Plätzchen backst, macht dich das nicht zu einem Bäcker. Wenn du deine Winterreifen selbst montierst, macht dich das nicht zu einem KFZ-Mechaniker. All diese arbeiten werden regelmäßig von Amateuren gemacht. Warum sollten wir Elektronik-Amateure nicht mit Arduino programmieren?
Michael schrieb: > Warum sollten wir Elektronik-Amateure nicht mit Arduino programmieren? natürlich darf man das, ist sogar gut wenn die Einstiegshürde niedrig liegt, aber wenn man mehr will stößt man bald an die Grenzen Genau wie bei Ikea, wenn man was anderes will als die Standards dann muss man halt zum Schreiner
Um mal im Paradigma der Zielgruppe zu bleiben: Arduino und das Ganze Zeugs ist im Grunde malen nach Zahlen. Und wer das schafft ist halt einfach allenfalls ein Anstreicher aber kein Maler.
Ich bin dafür in Zukunft alle Diskussionen die in die Richtung "Was bringt Arduino, für wen ist der etc." gehen zu schließen. Der Erkenntnissgewinn ist gleich null.
Arduino erlaubt C und Assembler Code. Nachdem es auf den avr-gcc setzt, gibt es keinen Unterschied zu jedem anderen AVR-Evalboard. Wenn man an die Grenzen der fertigen Arduino Libraries stösst, kann man sie meist auch lesen und umschreiben. Es ist dann eine Kleinigkeit z.B. mit WinAVR weiter zu machen... Fazit: preislich interessante AVR-Evalboards und einfache Entwicklungsumgebung für Einsteiger und Interessierte
me schrieb: > Arduino erlaubt C und Assembler Code. Nachdem es auf den avr-gcc setzt, > gibt es keinen Unterschied zu jedem anderen AVR-Evalboard. Doch die beschissenen Pin-Nummern. Ein Grund kein Arduino-Board zu kaufen. > Wenn man an die Grenzen der fertigen Arduino Libraries stösst, kann man > sie meist auch lesen und umschreiben. Es ist dann eine Kleinigkeit z.B. > mit WinAVR weiter zu machen... Was hat das dann noch mit Arduino zu tun? > Fazit: preislich interessante AVR-Evalboards und einfache > Entwicklungsumgebung für Einsteiger und Interessierte Günstig finde ich sie immernoch nicht. Ein Avr mit geätzter Platine ist günstiger und beinhaltet gleich noch die Funktionalität der teueren Shields. Das fertige selbst erstellte Board kostet weniger als jede Arduino Kombination. Bei der Entwicklungsumgebung kann ich dir zu zustimmen. Zu einfach und primitiv und damit nicht produktiv nutzbar.
avr schrieb: > me schrieb: > Zu einfach und > primitiv und damit nicht > produktiv nutzbar. Das ist kein Gegensatz sondern der Idealfall für Produktivität!
avr schrieb: Das fertige selbst erstellte Board kostet weniger als jede > Arduino Kombination. Ich habe hier einen Nano V3, AVR + FTDI + Kleinkram wie Spannungsregler + Platine, in der Bucht für nen 10er gekauft (in D.). Bau es billiger!
Herr Senken bringt es auf den Punkt: http://www.heise.de/forum/heise-Developer/Kommentare/Embedded-Programmierung-im-Umbruch/Im-Grunde-schon-ganz-richtig/posting-445626/show/ "Daher sehe ich Arduino sowohl als Fluch als auch als Segen. Immerhin bringt es endlich wieder Leute zur Hardware - da war eine Generation lang ja nur Software angesagt. Andererseits breitet sich in der Kielwelle ein Dilettantismus aus, der mich grauselt."
Wegen dem Preis vom Arduino ist das hier interessant: Mit dem chinesischen µC LGT8F88A sind Arduino Boards möglich, die 5 Dollar kosten, also weniger als 5 Euro. Dabei ist die chinesische Kopie LGT8F88A in einigen Punkten sogar leistungsstärker als das Original von Atmel. http://www.indiegogo.com/projects/iteaduino-lite-most-inexpensive-full-sized-arduino-derivative-board/x/4148639 http://imall.iteadstudio.com/lgt8f88a.html Beitrag "atmega88A clone"
Gut möglich das die Preise noch stärker sinken könnten, wenn die Industrie bzw. immer mehr Menschen Arduino Platinen kaufen.
Schöner Artikel, leider nur allzu wahr. Früher waren Programmierer noch echte Männer, heute sind es (fast) nur noch Java-Weicheier. Wenn ich überlege, was man damals aus C64, Amiga & Co mit ihren aus heuter Sicht geradezu lächerlichen Taktfrequenzen und Speichern geholt hat, dann sind 90% der Applikationen heute einfach nur diletantisch.
Falk Brunner schrieb: > Wenn ich überlege, was man damals aus C64, Amiga & Co mit ihren aus > heuter Sicht geradezu lächerlichen Taktfrequenzen und Speichern geholt > hat, dann sind 90% der Applikationen heute einfach nur diletantisch. Das stimmt so nicht, wenn du Bezug auf die Spieleentwicklung nimmst. Da nutzt man C/C++ und für einige zeitkritische Dinge bei der Engine auch Assembler. Moderne Spiele definieren einen aktuellen Durchschnitts PC oder orientieren sich an den festen Werten einer Spielekonsole und versuchen dann das beste dafür raus zu holen. Dabei werden viele Tricks und Künste angewandt, um mit einfachen Mitteln hohe Qualität zu erreichen usw.
Ich hatte an der Uni mal das Vergnügen mit ein paar Arduino Bastlern zu reden. Da schlägt einem die geballte Inkompetenz entgegen. Nahezu kein Hardwareverständnis. (gibt ja für alles Libs). Wenns dann ein bisschen weiter geht scheitern sie... Natürlich lockt man damit Leute zur Hardware - aber ob das für die das richtige Hobby ist bezweifle ich. Ich kenne keinen Entwickler der von Arduino zu richtiger Hardware gekommen wäre.
Johannes O. schrieb: > Ich kenne keinen Entwickler der von Arduino zu richtiger Hardware > gekommen wäre. So wie Java Entwickler niemals zu Treiber Entwicklung in C kommen :D Java ist für sie bereits der Höhepunkt der Entwicklung ;)
Johannes O. schrieb: > Ich hatte an der Uni mal das Vergnügen mit ein paar Arduino Bastlern zu > reden. > Da schlägt einem die geballte Inkompetenz entgegen. Nahezu kein > Hardwareverständnis. (gibt ja für alles Libs). Wenns dann ein bisschen > weiter geht scheitern sie... > Natürlich lockt man damit Leute zur Hardware - aber ob das für die das > richtige Hobby ist bezweifle ich. > > Ich kenne keinen Entwickler der von Arduino zu richtiger Hardware > gekommen wäre. Leute, Leute… gibt es für euch denn nur Wahl zwischen Perfektionismus und kompletter Inkompetenz? In meiner Welt existieren sehr viele Abstufungen zwischen diesen beiden Extremen. Gruß Michael (kopfschüttel)
@ KlausImHaus (Gast) >> hat, dann sind 90% der Applikationen heute einfach nur diletantisch. >Das stimmt so nicht, wenn du Bezug auf die Spieleentwicklung nimmst. Da >nutzt man C/C++ und für einige zeitkritische Dinge bei der Engine auch >Assembler. Das stimmt.
Falk Brunner schrieb: > Das stimmt. Das liegt daran das in der Spieleentwicklung die Hardware Ressourcen Goldwert sind. Nutzt man die Hardware Leistung besser aus entsteht ein besseres bzw. hübscheres Spiel und das kann die Verkaufszahlen erhöhen. In vielen anderen Bereichen gibt es diesen Faktor nicht bzw. es ist vernachlässigbar. Die meisten Programme führen keine aufwendigen Berechnungen durch. Dann fühlen sich viele nicht dazu verpflichtet ein effizientes Programm zu schreiben. Ob das so richtig ist oder nicht, ist denke ich nicht pauschal schwierig zu beurteilen. Es artet im Grunde zu einer moralischen Frage aus. Aus kapitalistischer Sicht entscheidet dann sowieso das Moral freie wirtschaftliche Denken ;D
>Früher waren Programmierer noch >echte Männer, heute sind es (fast) nur noch Java-Weicheier. >Wenn ich überlege, was man damals aus C64, Amiga & Co mit ihren aus >heuter Sicht geradezu lächerlichen Taktfrequenzen und Speichern geholt >hat, dann sind 90% der Applikationen heute einfach nur diletantisch. Ich mein, ich höre meine Opa reden. Früher war alles besser. Mein Opa hat früher auch die Nägel aus den alten Brettern gezogen und wieder grad geklopft. Heute gibts die zu diletantischen Preisen im Baumarkt. Oder bei Real. >90% der Applikationen heute Zu C64 Zeiten waren aber auch nur 10% der User am "rausholen". Die restlichen 90% waren beim StripPoker spielen bei 320x200 Pixel und 16 Farben. Apropos .. wie viel hat eigentlich ein Favicon ?!
Die optimale Lerntechnik für Elektronik, Programmierung und tausend praktischen Dingen ist "Learning by doing". Man kann es auch so formulieren: "Was man tut , das lernt man" Mit Arduino kann man ohne technische Einarbeitung ein paar hardwarenahe Applikationen laufen lassen. Also schnellen Erfolg bei geringen Lernaufwand, damit aber auch mit geringen Lerneffekt. Baut man sich dagegen seine uC-Evalkit selber, lernt man: -Schaltplan lesen, schaltung entwerfen und Fehler finden in schaltung -je nach dem ob man steckerbrett oder Loschrasterplatine verwendet lernt man auch Löten, Drähte abisolieren, schneiden, verzinnen Der finazielle Aufwand ist (nur) bei der Lötvariante deutlich höher, falls man nicht schon eine Lötstation im Haus hat. Man lernt also vieles, was man im Berufsleben als Eletroniker/Mechatroniker/Hardware-entwickler/-techniker braucht. Für einen Hardentwickler sind das alles im Berufsleben unverzichtbare Techniken. An universiellen Kulturtechnik lernt man nebenbei: -Fehler finden (Analyse, Problem eingrenzen, nachfragen oder Lit-recherche) -Fehler beheben (Eingeständnis eines Fehlers, Mut zur Änderung - "Irren ist menschlich") -Frust-toleranz, Mut zum Investrisiko, Vertrauen in die Vielfalt eigener Fähigkeiten Ob man Elektronik-aufbauen lernen will oder muß ist aber eine sehr individuelle Entscheidung die nur eine Minderheit mit Ja beantworten wird. Aber auch mit einem fertig gekaufen board kann man mehr lernen als ineffektiv an einer HAL (Hardware Abstraction layer) zu coden. Verwendet man ein Arduino board OHNE die Arduino Abstraktions-library lernt man: -Datenblatt lesen -Architectur von Mikrocontrollern -alle Einstellmöglichkeiten eines mikrocontrollers -aufsetzen einer entwicklungsumgebung/Toolchain -Programme auf Hardwareebene debuggen und die oben genannten universalen Kulturtechniken. Also vieles was man im Berufsleben als Embedded Programmierer (Technische Informatik) braucht. Und um der oben gennanten Forderung nach Abstraktion zu antworten, wer soll diese Abstraktion (-sschicht) schreiben|debuggen|optimieren, wenn nicht einer mit Detailkenntnissen um die zugrundeliegende Hardware. Das Arduino mit seiner Bibliothek erklärtermassen an Personen ohne techniches Detailwissen richtet kann man auch als Nachteil verstehen. Man wird dieses Detailwissen bei der Arbeit mit Arduino auch nicht erlernen, wenn man nicht bewußt auf den Library-Komfort verzichtet. Arduino ist kein Lernsystem für Mikrocontroller sondern ein Experimentier-/Spielkasten für Unbedarfte. Man KANN bei Verzicht auf die Bibliotheken und Studium der uC-Dokumentation wirklich uC-Experte werden, Arduino mit seinen Ansatz "Mikrocontroller für Warmduscher" fördert das aber nicht besonders.
KlausImHaus schrieb: > Das stimmt so nicht, wenn du Bezug auf die Spieleentwicklung nimmst. Da > nutzt man C/C++ und für einige zeitkritische Dinge bei der Engine auch > Assembler. Und heutzutage oft genug nicht mal das, sondern Flash, HTML mit JavaScript, Adobe Air, GameMaker Studio, RPG Maker, Unity, usw.
Hi, jetzt möchte ich mal auch meinen Senf ablassen. Nach fast über 7 Jahren, wo ich damals meine Atmega Applikationen auf Lochraster Platinen selbst herstellte und auch in C entwickelte, habe ich damit wieder begonnen. Angefangen habe ich damit eine MPU6050 über i2c auszulesen und erstmal über RS232 auszugeben. Einen Atmega habe ich auf eine Lochrasterplatine plaziert. Die Software habe ich wieder in C geschrieben. Da ich sogut wie aus der Übung war, hatte ich zwischendurch mit den Gedanken gespielt mir so ein Arduino zu beschaffen und die Software zusammen zu bauen, da ich an "wieder gekommene" Hürden gestoßen war. Ich bin aber hart geblieben und habe diese Hürden wieder gemeistert und siehe da es klappt. Mag vielleicht bei jedem anders sein, aber das Erfolgerlebnis bei einer gesamten Eigenentwicklung ist m.E. viel höher als wenn man etwas vorgekautes nimmt.
Mirki schrieb: > ......aber das Erfolgerlebnis bei einer > gesamten Eigenentwicklung ist m.E. viel höher als wenn man etwas > vorgekautes nimmt. Für mich ist alleine entscheidend was hinten raus kommt. Wenn ich mit etwas vorgekautem ein gutes Ergebnis erziele, dann wird es so gemacht. Mein Kunde hat nichts davon, wenn ICH das "Erfolgserlebnis der kompletten Eigenentwicklung" habe.
Moby schrieb: > avr schrieb: >> me schrieb: >> Zu einfach und >> primitiv und damit nicht >> produktiv nutzbar. > > Das ist kein Gegensatz sondern der Idealfall für Produktivität! Idealfall ist also: -kein hex-file -kein Projektexplorer -keine Auswahl der Toolchain -keine speziellen Compilereinstellungen -keine Makefile -kein nur-Flashen Button -kein IntelliSense -kein Syntax-Highlighting -nur Bootloaderunterstützung/kein ISP etc. -Dateiendungen, die man fast nirgends öffnen kann -...
Achja und natürlich: -kein Simulator -und damit keine Ansicht des listfiles (Assemblercode) und ähnliche Ausgaben -kein Debugger -externe Assembler-Code (*.S)?
Seht den Ardunio (Sowohl die Hardware, als auch die Software) einfach als Spielzeug, daß Interesse an richtiger Embedded-Technik wecken soll. Fakt ist: Mit der Ardunio-Oberfläche lernt man kaum was über die Grundlagen und das ist auch gar nicht das Ziel dieses "SDK". Aber der Ardunio nimmt die Hemmschwelle weg, eine LED in die Hand zu nehmen und auch real blinken zu lassen, als nur drüber zu lesen. Als ein solcher User sollte man jedoch nicht auf die Idee kommen, sich nun gleichauf mit Machern des V-USB-Projekts oder des IRMP zu sehen. Diesen Eindruck machen manche Threads der Ardunio-User. Ardunio und Beaglebone sind halt die neuen Designer-Einstiegsdrogen in unsere Welt - nicht mehr, nicht weniger. Die meißten Käufer werden nur kurz damit rumspielen, aber einige werden dann zu den härteren Drogen (PIC, AVR, ARM etc in C, asm, Bascom, Pascal...) greifen. Übrigens: ist euch schonmal aufgefallen, daß es zu den meißten ARMs kaum Assembler-Beispiele gibt? USB am STM32? Da seht ihr selbst bei ST lange Gesichter. Um keinen Streit vom Zaun zu brechen: Ja es ist in nahezu allen Fällen effektiver (Aufwand vs. Nutzen), auf einem ARM in C statt in Assembler zu programmieren! (Ausnahmen bestätigen die Regel). Aber das bedeutet nicht, daß es deshalb so gut wie keine ASM-Doku neben der IS-Liste geben kann. Mich wundert eher, daß kaum jemand danach fragt. Um wieder den Kreis zu den Ardunios zu schließen mal frech gefragt: Ist das nicht auch ein wenig der Ardunio-Weg= weg von der Hardware? ;)
Wenn ich eine LED blinken lassen möchte, dann nehme ich doch nicht gleich einen MC...das wäre ja, wenn ich eine Fliege mit einer Atom Bombe erschlagen will...Da nheme ich lieber eine FlipFlop Schaltung, oder beim Beispiel zu bleiben, eine Fliegen Klatsche
Mirki schrieb: > Wenn ich eine LED blinken lassen möchte, dann nehme ich doch nicht > gleich einen MC...das wäre ja, wenn ich eine Fliege mit einer Atom Bombe > erschlagen will...Da nheme ich lieber eine FlipFlop Schaltung Nein, eine Blink-LED ;-) Wobei die blinkende LED als das Hello-World der Mikrocontrollerei zu sehen ist, also als didaktisches Beispiel für den Einstieg. Auch beim Hello-World ist der Einsatz eines PCs rational gesehen gröbster Unfug, da man sich die beiden Wörter genauso gut auf Papier schreiben kann.
:
Bearbeitet durch Moderator
Mirki schrieb: > Wenn ich eine LED blinken lassen möchte, dann nehme ich doch nicht > gleich einen MC...das wäre ja, wenn ich eine Fliege mit einer Atom Bombe > erschlagen will...Da nheme ich lieber eine FlipFlop Schaltung, oder beim > Beispiel zu bleiben, eine Fliegen Klatsche Und wieviele Bauteile brauchst dafür? Das diskret aufzubauen, oder auch nur mit FlipFlop + Beschaltung wäre viel aufwändiger als ein kleiner Controller, der praktisch überhaupt keine Beschaltung mehr braucht. gruß cyblord
gut, mag ja sein, das welche die nicht in die Tiefe gehen wollen mit einem Arduino eher ans Ziel kommen, als wenn die es komplett von der picke aus machen....Aber mal Hand aufs Herz, bezeichnet man solche dann als MC entwickler oder gat Elektroniker? Ich denke das wäre falsch am Platz. Wer aber interesse an Elektronik und MC Entwicklung hat und dies erlernen möchte, der sollte zumindestens mit ein paar Grundschaltungen klarkommen, oder? Und das Beispiel mit dem "Hello World" ist so in etwa wie Äpfel mit Birnen vergleichen. Bei meinem Beispiel wird mit beiden Ansätzen eine LED zum Blinken gebracht, einmal mit einem MC und einmal ohne MC. Bei Deinem Beispiel wird das Hello World einmal am Bildschirm ausgegeben und einmal aufs Papier geschrieben......Der Vergleich hinkt!!
Mirki schrieb: > gut, mag ja sein, das welche die nicht in die Tiefe gehen wollen mit > einem Arduino eher ans Ziel kommen, als wenn die es komplett von der > picke aus machen....Aber mal Hand aufs Herz, bezeichnet man solche dann > als MC entwickler oder gat Elektroniker? Ich denke das wäre falsch am > Platz. Wer aber interesse an Elektronik und MC Entwicklung hat und dies > erlernen möchte, der sollte zumindestens mit ein paar Grundschaltungen > klarkommen, oder? Sehe ich ähnlich, Bastler die am Arduino festkleben sind die Script-Kiddies der Mikrocontrollerbranche. Es kann ein Hacker/Entwickler daraus werden, muß aber nicht. MfG, PS: Wer's nachschlagen muß : http://de.wikipedia.org/wiki/Script-Kiddie
Andy P. schrieb: > Übrigens: ist euch schonmal aufgefallen, daß es zu den meißten ARMs kaum > Assembler-Beispiele gibt? USB am STM32? Da seht ihr selbst bei ST lange > Gesichter. > Um keinen Streit vom Zaun zu brechen: Ja es ist in nahezu allen Fällen > effektiver (Aufwand vs. Nutzen), auf einem ARM in C statt in Assembler > zu programmieren! (Ausnahmen bestätigen die Regel). Assembler versus C aber garnix mit der Arduino-Diskussion hier zu tun. Man kann uC auch effektiv in C programmieren, wie das oben durchgekaute Beispiel des Port-bits setzen zeigt. Aber dazu muss man die uC-Architektur kennen und die Doku des Controllers gelesen haben. Und der Vergleich ARM - 8bit uc hinkt doch gewaltig. Die 1-8 kByte an Programmspeicher eines kleinen uC sind in Assembler fix gefüllt. Hardwarenahes C macht es da leichter mit der Speicherplatzverwaltung und Registerallokation für die Variablen und ist kaum ineffizienter. Dagegen verschwendet eine HAL Platz und Geschwindigkeit der bei den kleinen uC eh reichlich knapp ist. Und man lernt nix über die Interna. Ein ARM-System auf dem ein OS und Netzwerk protokollstack läuft, ist eine ganz andere Geschichte, da da 100+k an Codezeilen von mehreren Personen zu schreiben sind. MfG,
Fpga Kuechle schrieb: > Sehe ich ähnlich, Bastler die am Arduino festkleben sind die > Script-Kiddies > der Mikrocontrollerbranche. Es kann ein Hacker/Entwickler daraus werden, > muß aber nicht. > > MfG, Ich bin in meinem Beruf ein FW/SW Entwickler. Ich besitze zwar einen Arduino (warum auch nicht, bei 5 Euro), halte mich jetzt aber nicht für einen Script-Kiddie. Arduino kann man für all mögliche Zwecke einsetzen, wenn man schnell zu einem Ergebniss kommen möchte :) Außer die IDE finde ich die Arduino Welt recht interessant.
>Ich bin in meinem Beruf ein FW/SW Entwickler. Ich besitze zwar einen >Arduino (warum auch nicht, bei 5 Euro), halte mich jetzt aber nicht für >einen Script-Kiddie. Arduino kann man für all mögliche Zwecke einsetzen, >wenn man schnell zu einem Ergebniss kommen möchte Und man kann es gar nicht oft genug erwähnen, die Hardware lässt sich auch professionell programmieren: Beitrag "Re: Arduino mit Eclipse AVR-gcc Plugin programmieren" Btw.: Weis jemand, wie man die Toolchain für einen Arduino Due aufsetzt?
Johannes O. schrieb: Ich bin Softwareentwickler, der Elektronik nur als Hobby betreibt. Wenn ich den gesammelten Hochmut in diesem Forum betrachte, kann ich nur den Kopf schuetteln. > Ich hatte an der Uni mal das Vergnügen mit ein paar Arduino Bastlern zu > reden. Ich habe im Beruf regelmaessig das Vergnuegen, mit Elektronikern zu arbeiten. > Da schlägt einem die geballte Inkompetenz entgegen. Nahezu kein > Hardwareverständnis. Da schlaegt einem geballte Inkompetenz entgegen. Nahezu kein Verstaendnis fuer hoehere Programmiersprachen, Architektur von verteilten Applikation und komplexen Anwendungen. > (gibt ja für alles Libs). Wenns dann ein bisschen weiter geht scheitern sie... Die halten sich alle fuer ueberlegen, weil sie Assembler koennen und die Hardware im Detail kennen. Aber wenn's ein bisschen abstrakter und komplexer wird, scheitern sie. > Natürlich lockt man damit Leute zur Hardware - aber ob das für die das > richtige Hobby ist bezweifle ich. Ob die den richtigen Beruf gewaehlt habe, bezweifle ich nicht. Ich weiss, dass sie das nicht haben. > Ich kenne keinen Entwickler der von Arduino zu richtiger Hardware > gekommen wäre. Ich kenne keinen Elektroniker, der von der Elektronik zu richtiger Softwareentwicklung gekommen waere. Der Unterschied zu den Arduino-Bastlen: Von gelegentlichen, vom Bastelerfolg getriebenen Hoehenfluegen abgesehen, halten die sich nicht fuer Elektroniker. Schon gar nicht fuer die Besseren.
>Der Unterschied zu den Arduino-Bastlen: Von gelegentlichen, vom >Bastelerfolg getriebenen Hoehenfluegen abgesehen, halten die sich nicht >fuer Elektroniker. Schon gar nicht fuer die Besseren. Das ist auch nicht der Gegenstand der Arduino Welt. Wenn ein Kind mit 12 ein selbstgebautes RC Auto bauen will, drückst man ihm ja auch nicht Eagle, Ätzgerät, Tietze Schenk Buch und am besten Noch paar CortexM3 ICs in die Hand. Arduino mit dem ganzen (Spiel)Zeugt was dazu existiert, motiviert Menschen Projekte zu realisieren. Ich finde es gut, dass es solche Platform gibt und würde mich freuen, wenn wenn es weiter entwickelt wird.
Fpga Kuechle schrieb: > Sehe ich ähnlich, Bastler die am Arduino festkleben sind die > Script-Kiddies der Mikrocontrollerbranche. Der Vergleich hinkt.
Fpga Kuechle schrieb: > Die 1-8 kByte an > Programmspeicher eines kleinen uC sind in Assembler fix gefüllt. 8k Assembler? Ich glaube du sie solltest lieber in Programmieren. Das ist bei dir effizienter.
Dann ist ja myAVR noch unbrauchbarer. Wenn man einmal damit anfängt, hat man ein Problem ... weil: eigene Hardware, eigene IDE und wenig Beispiele
ajo schrieb: > 8k Assembler? Ich glaube du sie solltest lieber in Programmieren. Das > ist bei dir effizienter. 1.: In was? 2.: Vllt. war es je etwas Zeitkritischen.
In c. Wer 8 KB in Assembler schnell fühlt programmiert höchstwahrscheinlich in der falschen Sprache oder sollte noch viel lernen.
Hi >Da schlaegt einem geballte Inkompetenz entgegen. Nahezu kein >Verstaendnis fuer hoehere Programmiersprachen, Architektur von >verteilten Applikation und komplexen Anwendungen. >Die halten sich alle fuer ueberlegen, weil sie Assembler koennen und die >Hardware im Detail kennen. Aber wenn's ein bisschen abstrakter und >komplexer wird, scheitern sie. Sei froh. Wenn sie das auch noch könnten, wärst du überflüssig. >8k Assembler? Ich glaube du sie solltest lieber in Programmieren. Das >ist bei dir effizienter. >Wer 8 KB in Assembler schnell fühlt programmiert höchstwahrscheinlich in >der falschen Sprache oder sollte noch viel lernen. Anscheinend führen andere Programmiersprachen als Assembler bei manchen zur Verkümmerung der Fähigkeit sich verständlich auszudrücken. MfG Spess
Yalu X. schrieb: > Nein, eine Blink-LED ;-) Der ist gut! Ich bin auch so, mit den minimalsten Mitteln das gesuchte Ziel zu erreichen. Ich hab obige in der vor-MC-Zeit als Taktgeber eingesetzt. Das der Arduino eine eigene Sprache hat, hab ich erst hier erfahren. Wer damit nicht zufrieden ist, bitteschön, der kann dem Prozessor doch ein eigenes Programm verpassen. Und da er die 3D-Drucker steuert, kann er ja nicht so schlecht sein. Oder versteht der Prozessor nur Arduinisch? Genau so könnte man sich über Siemens LOGO aufregen. Was ist eigentlich da für ein Prozessor drin?
ajo schrieb: > In c. > Wer 8 KB in Assembler schnell fühlt programmiert höchstwahrscheinlich in > der falschen Sprache oder sollte noch viel lernen. Also ich beziehe mich auf kleine 8bit uc im Bereich von 1 bis 8k Befehlsspeicher. Das sind nun mal in Assembler mit 1 zeile pro Opcode 1000 bis 8000 Lines of Code; mit einem Makro-Assembler noch weniger. Also ein Programm kleiner Komplexität. Das ist zwar nicht in einer Stunde geschrieben, aber länger als ein paar Tage dauert es auch nicht. In hardwarenahen C sind das ebenso 1k bis 8k Codezeilen, da hier ebenfalls die Umrechnung 1 C-Instruction = 1 OpCode gilt. Bei Funktionsaufrufen mit Retten der Register auf den Stack sieht das zwar anders aus, aber mit einem Makroassembler ist häufiges Registersatz retten ebenfalls in einer Zeile (Macroauruf oder callSUB) abgehandelt. Da spart C kaum Schreibaufwand. Was leichter wird ist die Variablenverwaltung. Codieraufwand in C also ebenfalls ein paar Tage. Bibliotheken bspw f. 16 bit Arithmetik gibt es auch für Assembler, da gewinnt man auch nix wenn man auf C wechselt. Vergleicht man dagegen die Entwicklungszeiten von Assembler ohne Bibliotheken mit denen für die Verwendung von C mit Bibliotheken (bspw str.h) vergleicht man Äpfel mit Birnen. Es bleibt bei der Grundaussage: bei kleinen 8bit uc ist der Entwicklungswand in Assembler im Vergleich zu Maschinennahen C etwa gleich wegen gleicher Komplexität (nachgewiesen an etwa gleicher Zahl von LoC). Bei beiden Vorgehensweisen braucht man detailiertes Wissen über die uC-Interna, bei Assembler benötigt man zusätzliches Wissen über die Opcode Memnonics , bei C über C, C-Compiler (bspw. #pragma) und C-Fallstricke (bspw. volatile). Das tut sich nicht viel. Es ist also in diesem Fall m.E nicht viel anders, ob man Maschinenahes C oder Assembler verwendet. Das sauge ich mir nicht aus den Fingern, sondern sind Erfahrungswerte, bspw. aus der Implementierung einer FAT16 PCMCIA Datei-Schreiberroutine auf einem PIC mit ca 4k (ca. 1995). Zuerst wurden die FAT16 routinen auf einen DOS-PC in C mit direkten IO-Zugriff auf eine Platte realisiert, dann die C Routinen in PIC-Assembler umgesetzt. Der Aufwand für die C-Routinen war etwa gleich wie für die Assemblerroutinen. (was aufgrund der etwa selben Zahl von Codezeilen auch nicht verwundert). MfG,
Bald iss weihnachten. Hoffentlich bringt der Weihnachtsmann genug Arduinos mit :-)
Beitrag #5301247 wurde von einem Moderator gelöscht.
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.