Gurke, Ich denke es wird an der Zeit sich endlich mal mit µCern zu befassen. Habt Ihr irgendwelche Tipps, Empfehlungen etc. wie man damit starten soll? Internetseiten? Programmierungstipps? Wäre über paar Antworten erfreut.....
Schön, dass du uns weder deinen Kenntnisstand verraten, noch dich auf dieser Seite ungesehen hast. So wird das nichts. https://www.mikrocontroller.net/articles/Absolute_Beginner https://www.mikrocontroller.net/articles/Absolute_Beginner-AVR_Steckbrettprojekte Gruß Max
Patryk D. schrieb: > Ich denke es wird an der Zeit sich endlich mal mit µCern zu befassen. Warum? Was willst du mit einem solchen uC anfangen? Welche Aufgabe soll der erledigen? > Programmierungstipps? Welche Programmiersprache beherrscht du? Falls noch keine, dann lerne C. > Internetseiten? https://www.mikrocontroller.net/articles/AVR-Tutorial https://www.mikrocontroller.net/articles/AVR Einfach dort mal stöbern: https://www.mikrocontroller.net/articles/Hauptseite
:
Bearbeitet durch Moderator
Patryk D. schrieb: > Habt Ihr irgendwelche Tipps, Empfehlungen etc. wie man damit starten > soll? Guck mal hier ins Forum. Dann bekommst du einen Eindruck, was es alles gibt, was man damit machen kann und worauf man achten muss. Wenn du ein bisschen gelesen hast, meldest du dich einfach wieder. Allein die Suche nach "Anfänger" im Unterforum /µC & Elektronik/ fördert für das letzte Jahr 658 Threads zu Tage.
Ich habe mir schon die Microkontroller.net AVR Seite durchgelesen, aber ich will von euch wissen, wie Ihr damit so angefangen habt. Lothar schrieb: > Was willst du mit einem solchen uC anfangen? Welche Aufgabe > soll der erledigen? Zb ein Atmega8 timer mit 7 Segment Anzeigen, oder ne Motorsteuerung, sowas halt was man mit einem AVR machen kann. > Welche Programmiersprache beherrscht du? > Falls noch keine, dann lerne C. Bissle was über habe ich mir auf YT angeschaut, aber sonst keine.
Patryk D. schrieb: >> Welche Programmiersprache beherrscht du? >> Falls noch keine, dann lerne C. > Bissle was über habe ich mir auf YT angeschaut, aber sonst keine. Gut, kauf dir ein C-Buch und fang an zu programmieren. Dazu brauchst du noch gar keinen uC und musst auch nichts kaufen. Für erste Gehversuche in C reicht schon das hier: http://codepad.org/mb7jlnJb. Vom "Filmchen angucken" wirst du das auf jeden Fall nicht lernen. Du musst die Fehler selber machen...
Wenns dann schon um AVR geht, würde ich zb nen Atmega8 nehmen, und versuchen einfach ne LED zum Blinken zu bringen. Klar, natürlich nicht gleich mit dem Timer anfangen sondern erst die Basics.
Ich habe die Grundlagen von Transistorschaltungen und Logikgatter las Teenager aus Büchern gelernt. Dann hatte ich eine Ausbildung zum Kommunikationselektroniker und danach habe ich privat den Umgang mit µC Typen gelernt, die ich heute jedoch nicht mehr verwenden möchte. Damals musste man sich noch mit EPROMS herumschlagen. Ich empfehle Dir AVR oder PIC Mikrocontroller. Für den preisgünstigen Einstieg eignen sich momentan die Arduino Nano Boards sehr gut, denn sie enthalten bei weniger als 5 Euro einen Bootloader und ein USB Interface. Man kann sie ohne weitere Hardware direkt mit dem PC verbinden und programmieren. Allerdings rate ich von der Arduino Entwicklungsumgebung ab. Durch ihre vorgefertigten Libraries lenkt sie meiner Meinung nach zu sehr von den Grundlagen ab. Arduino Entwickler überschätzen ihre eigenen Fähigkeiten oft erheblich und stellen trotzdem saudumme Fragen. Benutze stattdessen für den Anfang einen Texteditor und den avr-gcc Compiler. Mit komplexeren Entwicklungsumgebungen beschäftigt man sich später, wenn man die Grundlagen verstanden hat. Apropos Grundlagen: Ich halte es für sinnvoll, möglichst früh ein bisschen in Assembler zu programmieren. Dann versteht man einige Eigenarten des C-Compilers besser. http://stefanfrings.de/avr_workshop/index.html http://stefanfrings.de/avr_hello_world/index.html http://stefanfrings.de/mikrocontroller_buch/index.html Ein bisschen spielerisch sind auch die Nibibee und Asuro Roboter, die eignen sich gut, wenn man die ersten Schritte bereits hinter sich hat. Last but not least: Schau Dir das AVR Tutorial hier an: https://www.mikrocontroller.net/articles/AVR-Tutorial https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial
Stefan U. schrieb: > Apropos Grundlagen: Ich halte es für sinnvoll, möglichst früh ein > bisschen in Assembler zu programmieren. Dann versteht man einige > Eigenarten des C-Compilers besser. Das ist richtig. Vor Allem hat man dann die Möglichkeit, sich bei "eigenartigen Fehlern" mal den vom C-Compiler erzeugten Assemblercode anzusehen und dem auf die Finger zu sehen...
Draco schrieb: > http://www.mikrocontroller.net/articles/AVR Mit AVR würde ich heute nicht mehr anfangen. Stefan U. schrieb: > Benutze stattdessen für den Anfang einen Texteditor und den avr-gcc > Compiler. Mit komplexeren Entwicklungsumgebungen beschäftigt man sich > später, wenn man die Grundlagen verstanden hat. Das kann ich so nicht unterschreiben. Besser gleich mit vernünftigen Werkzeugen arbeiten, und dazu gehört ein richtiger Debugger. Sonst besteht die Gefahr, dass man sich eine sehr umständliche Arbeitsweise bei der Fehlersuche angewöhnt. Stefan U. schrieb: > Apropos Grundlagen: Ich halte es für sinnvoll, möglichst früh ein > bisschen in Assembler zu programmieren. Dann versteht man einige > Eigenarten des C-Compilers besser. Das halte ich für optional. Kann man machen, aber der Mehrwert hält sich in Grenzen. Für einen Anfänger sowieso.
Wahrscheinlich wirst du noch hunderte ähnlich kontroverse Antworten erhalten. Wirklich wichtig ist, dass du anfängst. Kauf Dir ein paar Teile und lege los. Das bringt Dich schneller voran, als endlosen Diskussionen zu folgen. Für PIC und AVR wirst du problemlos genügend Anleitungen im Internet und im Buchhandel finden.
Stefan U. schrieb: > Für PIC und AVR wirst du problemlos genügend Anleitungen im Internet und > im Buchhandel finden. Gleiches gilt für STM32.
Claymore schrieb: > Mit AVR würde ich heute nicht mehr anfangen. Wenn man gleich von vorn herein mit einem 32-Bit ARM anfängt, dann kann es leicht sein, dass man sich in der Komplexität verstolpert. > Mit AVR würde ich heute nicht mehr anfangen. Ich auch nicht. Aber ich kenne mich inzwischen mit uCs auch ganz gut aus. Für den absoluten Anfang einen uC zu nehmen, der nicht viel kann, ist nicht falsch. Dann ist das relevante Datenblatt nicht soooooo arg dick... Beim ARM ist schon der Interruptcontroller komplexer als ein alter 8051 oder ein kleiner AVR. Oder Andersrum: wenn ich unbedingt "etwas fahren" möchte, dann ist ein Dreirad einfacher als ein ICE. Speziell am Anfang.
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Ich auch nicht. Aber ich kenne mich inzwischen mit uCs auch ganz gut > aus. Für den absoluten Anfang einen uC zu nehmen, der nicht viel kann, > ist nicht falsch. Dann ist das relevante Datenblatt nicht soooooo arg > dick... Das kommt drauf an, auf welcher Abstraktionsebene man einsteigen will. Assembler und Registerebene halte ich für Einsteiger eher ungeeignet und bei einer höheren Ebene spielt die Komplexität keine so große Rolle.
Claymore schrieb: > Das kann ich so nicht unterschreiben. Besser gleich mit vernünftigen > Werkzeugen arbeiten, und dazu gehört ein richtiger Debugger. Sonst > besteht die Gefahr, dass man sich eine sehr umständliche Arbeitsweise > bei der Fehlersuche angewöhnt. Naja Debugger hat's seit 30 Jahren bei mir nie gebraucht. Es geht auch ohne, wenn mal eine weitere Ausgabemöglichkeit hat und es versteht seinen Code auf Richtigkeit zu verifizieren.
Ich wusste, dass die ARM Controller wieder in die Runde geworfen werden. Natürlich von den Profis, die sich ganz doll gut auskennen. Außerdem ist ARM nicht gleich ARM. Die Irritationen beginnen schon damit, dass es zahlreiche inkompatible Programmier-Schnittstellen gibt und dass jeder Hersteller einen anderen Compiler empfiehlt. Dann geht es weiter mit einem Datenblatt, in dem typischerweise nur ein Bruchteil dessen drin steht, was man wissen muss. Man sollte eher von einem Satz an Datenblättern sprechen, die sich gegenseitig ergänzen und von denen jedes typischerweise über 100 Seiten lang ist. Das kann man doch keinem Anfänger empfehlen. Bedenkt mal, welchen Kenntnisstand der TO hat! Es ist ja nicht so, dass man für den Rest seines Lebens bei dem µC bleiben muss, mit dem man angefangen hat. Aber ganz sicher fängt der Konditor-Lehrling auch nicht mit einer dreistöckigen Hochzeitstorte an.
no Debugger schrieb: > Naja Debugger hat's seit 30 Jahren bei mir nie gebraucht. > > Es geht auch ohne, wenn mal eine weitere Ausgabemöglichkeit hat und es > versteht seinen Code auf Richtigkeit zu verifizieren. Ja, das ist die typische Aussage der Debugger-Verweigerer. Die werden nur nie erfahren, wie ineffizient ihre Arbeitsweise ist. Stefan U. schrieb: > Außerdem ist ARM nicht gleich ARM. Die Irritationen beginnen schon > damit, dass es zahlreiche inkompatible Programmier-Schnittstellen gibt > und dass jeder Hersteller einen anderen Compiler empfiehlt. Dann geht es > weiter mit einem Datenblatt, in dem typischerweise nur ein Bruchteil > dessen drin steht, was man wissen muss. Man sollte eher von einem Satz > an Datenblättern sprechen, die sich gegenseitig ergänzen und von denen > jedes typischerweise über 100 Seiten lang ist. Vorurteile. Stefan U. schrieb: > Das kann man doch keinem Anfänger empfehlen. Bedenkt mal, welchen > Kenntnisstand der TO hat! Dann aber Assembler empfehlen!!
Claymore schrieb: > Vorurteile. Gegenbeweise, bitte. > Stefan U. schrieb: >> Das kann man doch keinem Anfänger empfehlen. Bedenkt mal, welchen >> Kenntnisstand der TO hat! > Dann aber Assembler empfehlen!! Natürlich ist es unsinnig, auf einem ARM mit Assembler anzufangen. Aber man kommt mit einem Dreizeiler bei einem AVR und PIC auch in Assembler zu einem ansehnlichen Ergebnis und weiß dann schon mal, was der uC alles tun muss, um den gewünschten Effekt zu haben. Und wenn man dann noch was komplexeres macht, dass wird einem bei jeder C-Zeile, die man später hinschreibt, klar, dass z.B. eine Quadratwurzelberechnung einfach Zeit kostet, weil der uC viel zu tun hat. Und das, obwohl es nur ein sqrt() in C ist...
> Debugger-Verweigerer. Die werden nur nie > erfahren, wie ineffizient ihre Arbeitsweise ist. Ja ist klar. Jedem das Seine. PS: Ich habe einen Debugger, nutze ihn aber nur selten. Selbst in Java Web-Anwendungen (ganz anderes Feld, weiss ich) nutze ich den Debugger nur selten, obwohl der prinzipiell richtig prima ist. Warum das so ist, verrate ich nicht. Ich hab nämlich keine Lust, von Dir bekehrt zu werden. Wegen der ARM Datenblätter: > Vorurteile. Nein, das ist meine persönliche Erfahrung. > Dann aber Assembler empfehlen!! Ein BISSCHEN Assembler habe ich OPTIONAL empfohlen. Kann man auch bleiben lassen.
Arduino oder BASCOM sind für den Einstieg recht gut, auch wenn beiden das Frickelimage anhaftet. Aber der Anfänger braucht erstmal schnelle Erfolgserlebnisse. Durch das Assembler-Bootcamp sollte man heute keinen mehr schleifen (müssen). Wenn man mehr will und auch Zeit und Energie investieren kann/will, lernt man dann das komplette C bzw. sogar C++!
> Wenn man mehr will und auch Zeit und Energie > investieren kann/will, lernt man dann das komplette C bzw. sogar C++! Ich tu mich schwer, mir vorzustellen, wie man die Arduino Entwicklungsumgebung ohne komplettes C bzw. C++ benutzen soll. Fährt man heutzutage auch Auto, ohne in die Fahrschule zu gehen? Konstruiert man einen Dachstuhl, ohne Ahnung von Statik und Mathematik zu haben?
Hi, ich schildere mal meine Erfahrungen. Ich bin völlig fachfremder µC-Bastler. (Kaufmann Wohnungswirtschaft) Ich bastle schon lange zur Entspannung und habe vor nicht allzu langer Zeit mit den ARMs begonnen. Ich habe mir bewußt einen ganz einfachen ausgesucht, den STM32F030F4 mit 20 Pins. datasheet 96 Seiten reference manual 771 Seiten errate sheet 10 Seiten programming manual 91 Seiten (nur nötig, wenn ASM benutzt wird) Alles in Englisch, in allen Dokumenten wird ein grundsätzliches µC und Elektronik-Knowhow absolut vorausgesetzt, sonst findest Du keinen Einstieg. Gut, dass ich vorher schon viel mit 8-Bittern (AVR, STM8) rumgemacht habe, sonst wäre ich hoffnungslos untergegangen. Es ist trotzdem mühsam, zumal fürs Basteln nie ein voller Tag zur Verfügung steht, sondern meist nur immer ein paar Stunden. Man muss sich immer wieder erst neu reinfinden. Mein Rat: fang mit dem einfachsten und billigsten 8-Bitter an, den Du finden kannst. Alternativ mit dem Arduino und einer passenden C-Programmierumgebung, z. B. dem gcc.
@ Stefan Us (stefanus) >Ich tu mich schwer, mir vorzustellen, wie man die Arduino >Entwicklungsumgebung ohne komplettes C bzw. C++ benutzen soll. Das ist dein Problem! Es geht um das ANFANGEN! >Fährt man heutzutage auch Auto, ohne in die Fahrschule zu gehen? Nö, aber man fängt klein an, auf dem Dreirad (=Arduino). Dann kann man mehr lernen, auch C/C++ (Fahrschule). Man fängt nicht mit dem Formel 1 Renner an! >Konstruiert man einen Dachstuhl, ohne Ahnung von Statik und Mathematik >zu haben? Niemand hat die Absicht, einen Dachstuhl zu konstruieren ;-)
>Fährt man heutzutage auch Auto, ohne in die Fahrschule zu gehen?
Nachtrag: Natürlich muss man auch bei BASCOM und Arduino die Grundlagen
lernen, sonst ist auch dort nach dem Kopieren von Sketches schnell
Schicht im Schacht! Dazu braucht man ein GUTES Lehrbuch, die Doku von
BASCOM oder Arduino reicht bei weitem NICHT!
Falk B. schrieb: > Arduino oder BASCOM sind für den Einstieg recht gut, auch wenn beiden > das Frickelimage anhaftet. Aber der Anfänger braucht erstmal schnelle > Erfolgserlebnisse. Wäre ebenfalls meine Empfehlung. Vor einigen Jahren hätte ich direkt hier auf das AVR Tutorial verwiesen, aber das ist für "n00bs" wahrscheinlich ein wenig zu hoch. Nehm einen Arduino, da haste alles was du brauchst und so viele Beispiele das man da sehr schnell einen Einstieg findet und die ersten Erfolgserlebnisse nicht lange auf sich warten lassen. Die Grundkonzepte kann man da auch einigermaßen erlernen und man weiß worum es geht. Wenn dann die Motivation nicht verflogen ist und immer noch Interesse an µC besteht kannst du dir das AVR Tutorial ansehen und ordentliches Programmieren lernen. Anschließend kann man sich immer noch einen ARM vornehmen, wie z.B. einen Arduino DUE (dann bleibts in der Atmel Familie) oder STM32 oder ... oder ... oder ... oder ....
Stefan schrieb: > Wahrscheinlich wirst du noch hunderte ähnlich kontroverse Antworten > erhalten. Wird ja alleine 2 Stunden dauern um die durchzulesen ;D
> Das kommt drauf an, auf welcher Abstraktionsebene man einsteigen will. > Assembler und Registerebene halte ich für Einsteiger eher ungeeignet und > bei einer höheren Ebene spielt die Komplexität keine so große Rolle. Genau darum geht ein Arduino mit ArduinoIDE auch, besonders für n00bs welche sich erst an die Denke des Programmierens ranzutasten brauchen. Auch richtig ist dass die Qualität hinter der Kulisse von Arduino nicht die beste ist. Ob man nun die ersten Schritte C/C++ (also Variablen, Funktionen, Kontrollstrukturen, einfache Algorithmen) auf Tischrecner oder Arduino tut spielt keine Rolle. Wenn's dann ans Eingemachte geht, bekommt mann sowieso eigene Lieblingsgeschmäcker: die einen f. AVRs, andere f. Kinetis, jene f. 8 bits, andere f. Hochsprachen usw. Einigung ist dann nicht mehr möglich ;-) Selbständigkeit ist dann gefragt.
Claymore schrieb: > Stefan U. schrieb: >> Benutze stattdessen für den Anfang einen Texteditor und den avr-gcc >> Compiler. Mit komplexeren Entwicklungsumgebungen beschäftigt man sich >> später, wenn man die Grundlagen verstanden hat. > > Das kann ich so nicht unterschreiben. Besser gleich mit vernünftigen > Werkzeugen arbeiten, und dazu gehört ein richtiger Debugger. Das eine hat mit dem anderen erstmal nichts zu tun. Ich finde es durchaus auch sinnvoll, zu verstehen, was der Compiler und der Linker tut, wie sie sich die Arbeit aufteilen und wie so dann aus dem Quellcode ein ausführbares Programm wird. Auch Makefiles sollte man grundlegend verstanden haben. Eine IDE versteckt das alles, und wenn man mal mehr als die Voreinstellungen braucht, hat man keine Ahnung, wie das funktioniert. Claymore schrieb: > Stefan U. schrieb: >> Apropos Grundlagen: Ich halte es für sinnvoll, möglichst früh ein >> bisschen in Assembler zu programmieren. Dann versteht man einige >> Eigenarten des C-Compilers besser. > > Das halte ich für optional. Kann man machen, aber der Mehrwert hält sich > in Grenzen. Für einen Anfänger sowieso. Bei einem AVR ist der Assembler recht leicht zu verstehen. Es kommt letztendlich auch darauf an, was man will. Ist die µC-Programmierung etwas, das man als Beiwerk braucht für das, was man eigentlich machen will, oder ist die eher der primäre Zweck? In letzterem Fall würde ich es auch empfehlen, Assembler zu lernen. Stefan U. schrieb: > Wirklich wichtig ist, dass du anfängst. Kauf Dir ein paar Teile und lege > los. Das bringt Dich schneller voran, als endlosen Diskussionen zu > folgen. Ja, aber die Grundlagen von C würde ich trotzdem erstmal auf dem PC lernen und dann auf den µC übertragen. Man muss nicht erst zum Programmiergott werden, bevor man mit den µCs anfängt, aber wenigstens die absoluten Grundlagen schon zu beherrschen ist kein Fehler. Das Ausprobieren und Debuggen des Code ist auf dem PC einfacher. Lothar M. schrieb: >> Mit AVR würde ich heute nicht mehr anfangen. > Ich auch nicht. Aber ich kenne mich inzwischen mit uCs auch ganz gut > aus. Für den absoluten Anfang einen uC zu nehmen, der nicht viel kann, > ist nicht falsch. Dann ist das relevante Datenblatt nicht soooooo arg > dick... So habe ich das gemacht. Ich habe mir einen ATtiny13 genommen und dessen Datenblatt komplett durchgelesen. Dann ein paar Programme in Assembler geschrieben und dann auf C und größere AVRs umgestiegen (wobei ich C allgemein vorher schon sehr gut kannte). Diese Art von Einstieg ist aber sicher nicht für jeden das richtige. > Oder Andersrum: wenn ich unbedingt "etwas fahren" möchte, dann ist ein > Dreirad einfacher als ein ICE. Speziell am Anfang. Beim Dreirad muss ich lenken, beim ICE nicht. ;-) Stefan U. schrieb: > Es ist ja nicht so, dass man für den Rest seines Lebens bei dem µC > bleiben muss, mit dem man angefangen hat. Richtig. Für den Einstieg was möglichst einfaches zu nehemen, ist kein Fehler. Wenn man das Prinzip mal verstanden hat und sowieso in C programmiert, ist ein Umstieg nachher dann auch nicht mehr so schwer. Claymore schrieb: > no Debugger schrieb: >> Naja Debugger hat's seit 30 Jahren bei mir nie gebraucht. >> >> Es geht auch ohne, wenn mal eine weitere Ausgabemöglichkeit hat und es >> versteht seinen Code auf Richtigkeit zu verifizieren. > > Ja, das ist die typische Aussage der Debugger-Verweigerer. Die werden > nur nie erfahren, wie ineffizient ihre Arbeitsweise ist. Ich finde, es kommt drauf an. Manchmal ist der Debugger die einfachere Möglichkeit, manchmal die Debug-Ausgaben oder -Anzeigen. Es kommt meines Erachtens immer auf den Einzelfall an. > Stefan U. schrieb: >> Außerdem ist ARM nicht gleich ARM. Die Irritationen beginnen schon >> damit, dass es zahlreiche inkompatible Programmier-Schnittstellen gibt >> und dass jeder Hersteller einen anderen Compiler empfiehlt. Dann geht es >> weiter mit einem Datenblatt, in dem typischerweise nur ein Bruchteil >> dessen drin steht, was man wissen muss. Man sollte eher von einem Satz >> an Datenblättern sprechen, die sich gegenseitig ergänzen und von denen >> jedes typischerweise über 100 Seiten lang ist. > > Vorurteile. Wohl eher Praxis-Erfahrung. Zumindest entspricht das meiner Erfahrung mit ARM-Prozessoren. > Stefan U. schrieb: >> Das kann man doch keinem Anfänger empfehlen. Bedenkt mal, welchen >> Kenntnisstand der TO hat! > > Dann aber Assembler empfehlen!! Auf einem ARM würde ich den auch keinem empfehlen. Auf dem AVR schon.
Claymore schrieb: > Das halte ich für optional. Kann man machen, aber der Mehrwert hält sich > in Grenzen. Für einen Anfänger sowieso. Es hat noch niemand geschadet, zu wissen was er tut oder anrichtet, wenn er später in einer höheren Programmiersprache irgendwelche Tools verwendet oder ach so bequeme Libraries einbindet. Hinterher ist das Geschrei groß, wenn auf einem kleinen µC eine unbedachte Float-Operation oder ein Printf() plötzlich den Speicher verstopfen. Man kann natürlich auch auf dem Standpunkt stehen, dass sich effiziente Programme vor allem durch möglichst geringe Nutzung der Resource Gehirn auszeichnen.
Hallo, Claymore schrieb: > Stefan U. schrieb: >> Benutze stattdessen für den Anfang einen Texteditor und den avr-gcc >> Compiler. Mit komplexeren Entwicklungsumgebungen beschäftigt man sich >> später, wenn man die Grundlagen verstanden hat. > > Das kann ich so nicht unterschreiben. Besser gleich mit vernünftigen > Werkzeugen arbeiten, und dazu gehört ein richtiger Debugger. Sonst > besteht die Gefahr, dass man sich eine sehr umständliche Arbeitsweise > bei der Fehlersuche angewöhnt. Ein Debugger ist nur so gut wie der Kenntnisstand des Benutzers. Als ich anfing gab es keine Debugger oder welcher Z80-Debugger wäre hätte es sein sollen? Man mußte sich den eigenen Kopf zerbrechen und Hilfsmittel nutzen. Eine LED am Portpin oder eben die serielle Schnittstelle. Beides gibt es immernoch für jeden nutzbar. Testen, ob ein Programmpunkt überhaupt erreicht wird, sich die Inhalte einiger Variablen auszugeben, geht damit problemlos. Man muß anhand des eigenen Programms ohnhin ergründen warum in Variable x nicht die erwartete 10 sondern 85 steht. Nur ganau das muß man nachen und können. Hilfloses studieren aller Registerinhalte und darüber ewig rätseln, wie der Inhalt JEDES Registers zustandegekommen ist, koste Zeit und hilft nicht weiter. Genau das passiert aber gern, wenn man einen komplexen Debugger hat und meint, der findet Fehler schneller. DebugWire auf einem ATTiny ist praktisch, bis man es aber wirklich mal braucht, hat man schon etliche Projekte ohne erledigt. Eine Tafel mit 100 Instrumenten nutzt mir im Problemfall garnichts, wenn ich nicht weiß, auf welches ich bei Problem x schauen muß. Wenn ich das aber weiß, dann reicht genau ein Instrument. Gruß aus Berlin Michael
Also Ich bin kein Vollprofi in Sachen µC programmieren, kann auch kaum/nicht Assembler. Ich programmiere seit ca.1 Jahr µC(vorher aber andere Sprachen) und bei mir ist es so: Ich habe einen Arduino nano/Uno und ein Stk500 mit ua. Atmega8 zu Hause und wenn ich schnell etwas programmieren möchte, habe ich auch bis noch nicht allzu langer Zeit lieber auf den Arduinos mit USB interface programmiert, als mich erst in die Ansteuerung des Boards reinzufuchsen. Inzwischen tut sich da nicht mehr SO viel. Da hab ich dann schnell Erfolge, als mich erst über die genaue Erzeugung eines Signals Gedanken zu machen. ...Eig ist es bei mir so, Ich beschäftige mich x Stunden durchschnittlich damit und dann merke ich schon wie ich automatisch besser werde. MMn ist das wichtigste Spass an µC und programmieren zu haben, dann kommt der Rest schon von alleine mit der Zeit.
Falk B. schrieb: > Arduino oder BASCOM sind für den Einstieg recht gut Warum nicht LunaAVR? http://avr.myluna.de/doku.php Hat doch alles was es für erste Erfolge braucht. http://avr.myluna.de/lib/exe/fetch.php?media=de:2013r6.jpg
Lothar M. schrieb: > Claymore schrieb: >> Vorurteile. > Gegenbeweise, bitte. Die Datenblätter des STM32. Aber darum geht es gar nicht. Die Arbeit auf Registerebene ist für einen Anfänger immer (auch bei AVR) eine riesige Einstiegshürde, mit einer HAL dagegen kann jeder, der auf PC programmieren kann, viel besser umgehen. Das ist zumindest meine Erfahrung. Lothar M. schrieb: > Natürlich ist es unsinnig, auf einem ARM mit Assembler anzufangen. Aber > man kommt mit einem Dreizeiler bei einem AVR und PIC auch in Assembler > zu einem ansehnlichen Ergebnis und weiß dann schon mal, was der uC > alles tun muss, um den gewünschten Effekt zu haben. Hier tappst du in die gleiche Falle, die du mir vorgeworfen hast. Um Assembler zu verstehen, muss man sich erst einmal sehr tiefes theoretisches Wissen aneignen. Man muss sehr gut verstehen, wie ein Prozessor funktioniert, bevor man auch nur eine Zeile Assemblercode schreiben kann. Das ist für einen Anfänger eine riesige Hürde. Rolf M. schrieb: > Ich finde, es kommt drauf an. Manchmal ist der Debugger die einfachere > Möglichkeit, manchmal die Debug-Ausgaben oder -Anzeigen. Es kommt meines > Erachtens immer auf den Einzelfall an. Natürlich braucht man beide Methoden, das habe ich auch nie bestritten. Aber wenn man keinen Debugger benutzt, verschenkt man eine Menge Möglichkeiten, die man mit ineffizienten Methoden ersetzen muss.
Claymore schrieb: > [eine ganze Menge vernünftiger Argumente] Wir reden hier nicht von einem E-Ing. oder einem Informatikstudenten, sondern von einem Anfänger bei Null. Auf akademischen Niveau sind Deine Argumente alle vernünftig und richtig. Aber wir reden hier von jemandem, der damit nicht Geld verdienen und das den ganzen Tag lang machen will, demzufolge bis in die absolutesten Tiefen einsteigen muss, sondern von einem Bastler mit begrenztem Zeit- und Geduldbudget, dem ein grundlegendes Verständnis reicht, um seine LEDs auf dem Steckbrett blinken und seine Schrittmotore drehen zu lassen.
Claymore schrieb: > Man muss sehr gut verstehen, wie ein Prozessor funktioniert, bevor man > auch nur eine Zeile Assemblercode schreiben kann. Das ist für einen > Anfänger eine riesige Hürde. In Zeiten von "mal eben schnell" und "plug-and-play" ist das natürlich ganz pöse. Wo kämen wir denn hin, wenn jeder wüsste, was er tut. Die schnell mal eingebundenen Bibliotheken fallen übrigens auch nicht vom Himmel, sondern das muss sich auch jemand hinsetzen und gucken, wie irgendein Sensor auf Registerebene behandelt werden will. Und wehe, "plug-and-play" spielt nicht. Dann steht man ohne Grundlagenwissen schnell doof da und das Geschrei ist groß, weil man nicht weiss, wo man anfangen soll, um Fehlern auf den Grund zu gehen. Gerade auf µC kommt man um die Register-Ebene nicht drumrum, wenn man nicht nur auf ausgetretenen Pfaden irgendetwas abkupfern will.
google schrieb: > Wir reden hier nicht von einem E-Ing. oder einem Informatikstudenten, > sondern von einem Anfänger bei Null. > > Auf akademischen Niveau sind Deine Argumente alle vernünftig und > richtig. Nein, ganz im Gegenteil. Gerade als blutiger Anfänger ohne elektrotechnische oder informationstechnische Grundausbildung ist Low-Level-Programmierung (und dann noch in Assembler) eine sehr riesige Hürde. Deshalb würde ich High-Level-Programmierung (also zumindest mit einer HAL, meinetwegen auch Arduino) vorschlagen. Welche Prozessorplattform darunter steckt, spielt dann keine Rolle. Das kann dann meinetwegen auch wieder ein AVR sein.
Wolfgang schrieb: > In Zeiten von "mal eben schnell" und "plug-and-play" ist das natürlich > ganz pöse. Wo kämen wir denn hin, wenn jeder wüsste, was er tut. Von einem Profi mit einer formalen Ausbildung sollte man natürlich ein tiefes Wissen erwarten. Von einem Bastler muss man das nicht. Wolfgang schrieb: > Die schnell mal eingebundenen Bibliotheken fallen übrigens auch nicht > vom Himmel, sondern das muss sich auch jemand hinsetzen und gucken, wie > irgendein Sensor auf Registerebene behandelt werden will. Das kann ja ein Profi machen. Wieso sollte man das einem Anfänger zumuten? Wolfgang schrieb: > Dann steht man ohne > Grundlagenwissen schnell doof da und das Geschrei ist groß, weil man > nicht weiss, wo man anfangen soll, um Fehlern auf den Grund zu gehen. Also besser den Leuten, die sich damit nicht beschäftigen wollen, den Einstieg ganz verbieten, wenn sie keine theoretische Prüfung über Prozessortechnik schaffen? Wolfgang schrieb: > Gerade auf µC kommt man um die Register-Ebene nicht drumrum, wenn man > nicht nur auf ausgetretenen Pfaden irgendetwas abkupfern will. Das ist ziemlicher Blödsinn. Mit einer vernünftigen HAL oder einem RTOS kann man auf Anwendungsseite viel mehr machen, bei weniger Initialaufwand.
@ ach ja doch (Gast) >> Arduino oder BASCOM sind für den Einstieg recht gut >Warum nicht LunaAVR? Meinetwegen auch das, ich kenn LunaAVR nicht wirklich, eigentlich nur den Namen. Was mir daran nicht gefällt ist, daß es das Rad "neu" erfindet. Eine Sprache, ähnlich C aber dennoch kein C. Das ist was für Liebhaber von Exoten. Die meisten sind mit C(C++) deutlich besser bedient, das ist Standard und dementsprechend verbreitet.
> Man muss sehr gut verstehen, wie ein > Prozessor funktioniert, bevor man auch nur eine Zeile > Assemblercode schreiben kann. Das ist für einen Anfänger > eine riesige Hürde. Dieses Argument leuchtet mir nicht ein. Möglicherweise, weil ich mit Assembler angefangen habe. Bei viele Mikrocontrollern (so auch AVR) kann ich mit einer einzigen Assembler Zeile eine LED einschalten:
1 | #include "tn13def.inc" |
2 | sbi ddrb,1 |
3 | ende: |
4 | rjmp ende |
Und ich brauche nur einen zweiten Befehl, um daraus ein vollständiges Programm zu machen. Zwei Befehle, von denen einer eine 1:1 Beziehung zur Hardware und dem Datenblatt hat. Was ist daran komliziert? Wo ist das Problem? Das gleiche Programm sieht für jemanden, der noch nie programmiert hat, in C übrigens nicht einfacher aus:
1 | #include <avr/io.h> |
2 | |
3 | void main() |
4 | {
|
5 | DDRB |= (1<<1); |
6 | while(1); |
7 | } |
Klar, das war ein Extrem Beispiel. Doch fangen ANfänger mit derart einfachen Programmen an, sollte man meinen. Ich möchte heute niemanden mehr dazu drängen, das ERSTE Programm in Assembler zu schreiben. C ist sicher einfacher und ohnehin quasi Standard. Empfehlenswert ist ein bisschen Assebler dennoch, vor allem wenn man den C Compiler verdächtigt, falschen Code erzeugt zu haben. Gerade Anfängern passiert das öfters. Nicht umsonst werden "seltsame" Verhaltensweisen von C hier im Forum häufig anhand des generierten Assembler Codes erklärt und auch optimiert. Auch wenn am Ende doch nur der C Quelltext verbessert wird.
Claymore schrieb: > Hürde. Deshalb würde ich High-Level-Programmierung (also zumindest mit > einer HAL, meinetwegen auch Arduino) vorschlagen. > > Welche Prozessorplattform darunter steckt, spielt dann keine Rolle. Das > kann dann meinetwegen auch wieder ein AVR sein. Das meine ich. Wenn es auf hohem Abstraktionsniveau und somit egal ist, womit er anfängt, dann reicht das in Bastler/Maker-Kreisen am weitesten verbreitete und unterstützte aus, also Arduino/AVR. Und wenn er vertiefen will, hat er einen 8-Bitter drunter, den man gut durchschauen kann, weil alles (im Vergleich zu den ARMen) noch sehr wenig kompliziert ist.
>Warum nicht LunaAVR? Ich glaube, bisher hat in diesem Thread noch niemand von LunaAVR abgeraten. Ich kann es nicht empfehlen, weil ich davon 0,0 Ahnung habe. Aber du kannst es vielleicht empfehlen. Schreib uns doch mal, warum Dir LunaAVR besonders gefällt und wo die wesentlichen Unterschiede zu den bisherigen Vorschlägen (C, C++, BASCOM) sind. Was ich prima finde: Für AVR Mikrocontroller hat man freie Wahl zwischen zahlreichen Programmiersprachen. Ist das bei anderen µC auch so?
Stefan U. schrieb: > Zwei Befehle, von denen einer eine 1:1 Beziehung zur > Hardware und dem Datenblatt hat. Was ist daran komliziert? Wo ist das > Problem? Dass man etwas mehr machen möchte als eine LED einschalten, sollte eigentlich logisch sein. Spätestens wenn man arithmetische Funktionen umsetzen will, muss man sich schon tiefer mit der Architektur beschäftigen. Für jemanden ohne entsprechende Vorbildung ist das nicht so einfach wie du es dir vorstellst. Stefan U. schrieb: > Das gleiche Programm sieht für jemanden, der noch nie programmiert hat, > in C übrigens nicht einfacher aus: Dass Arbeit auf Registerebene für einen Einsteiger immer eine größere Hürde ist, habe ich ja schon mehrfach erwähnt.
Stefan U. schrieb: > Was ich prima finde: Für AVR Mikrocontroller hat man freie Wahl zwischen > zahlreichen Programmiersprachen. Ist das bei anderen µC auch so? Die Auswahl ist bei anderen Controllern eher größer.
>Um Assembler zu verstehen, muss man sich erst einmal sehr tiefes >theoretisches Wissen aneignen. Man muss sehr gut verstehen, wie ein >Prozessor funktioniert, bevor man auch nur eine Zeile Assemblercode >schreiben kann. Bullshit, um auf einem 8Nit-AVR eine LED blinken zu lassen muß ich weder Assembler "studieren", noch die Prozessorarchitektur im Detail verstehen. Ja, ihr Profis seid wirklich ungemein gescheit. Da ist es schon fast Gotteslästerung, wenn man viele Sachen auch ohne unnötigen Studium hinbekommt.
google schrieb: > Wenn es auf hohem Abstraktionsniveau und somit egal ist, > womit er anfängt, dann reicht das in Bastler/Maker-Kreisen am weitesten > verbreitete und unterstützte aus, also Arduino/AVR. Gerade Arduino ist ein gutes Beispiel. Schon wenn man einfach nur mal einen kurzen Puls auf einem Pin erzeugen will, ist man mit dem ach so tollen Abstraktionslevel am Ende. Da ist es schon sehr hilfreich, wenn nicht schon bei digitalWrite() der Horizont kommt, sondern man noch etwas mehr vom System weiß. Man muss nicht immer auf Registerebene runter gehen, aber in kritischen Fällen erleichtert es die Dinge ungemein, wenn man damit umgehen kann. Und das lernt man in Assembler - ganz direkt an der Hardware.
Wegen High-Level Programmierung versus Low-Level Programmierung: Ich habe Computertechnik von "unten" nach "oben" gelernt. Zuerst habe ich mich mit Logikgattern, Speicher, ALU, Netzteilen, CRT Bildschirmen, etc beschäftigt. Ich wusste, wie der C64 funktioniert, bevor ich ihn zum ersten mal auf dem Tisch stehen hatte. Und dann habe ich den zuerst in Assembler programmiert, was wohl auch daran lag, das dessen Basic sehr bescheiden war. Letztendlich musste ich mich zwangsläufig mit den Registern der ganzen Chips befassen. Für mich hat sich das allerdings ganz "natürlich" angefühlt. Wenn ich einen Pin am User-Port abfragen will, muss ich den dahinter liegenden Chip ansprechen. Und der stellt laut Datenblatt seine Funktionen über die Register bereit. Also spreche ich Register an. Was sonst? PC's programmiere ich inzwischen mit Hilfe von Betriebsystem und Frameworks auf High-Level Ebene. Also kenne ich auch den umgekehrten Weg. Am PC erreiche ich mit wenigen Zeilen Code großartige Sachen. Da lese ich nicht mehr hunderte Seiten Datenblätter, sondern hunderte Seiten Anleitungen von Frameworks. Beim PC habe ich nur ganz vage Ahnung von dem, was sich innerhalb des Gehäuses abspielt, wenn ich z.B. einen SOAP Service programmiere. Zurück zur Hardware: Wenn ich meine Modelleisenbahn mit dem PC verbinde, brauche ich ein Interface, das ich Low-Level programmieren kann. Wo ich jedes Bit einzeln setzen und abfragen kann. Dazu schließe ich einen µC an den USB Bus an und den programmiere ich dann wieder auf Registerebene. Ich Maße mir allerdings nicht an, den einen oder anderen Weg als falsch zu bezeichnen. Viele Wege führen nach Rom. Als Elektroniker fühlt sich das Programmieren von Bits und Registern natürlicher an, als abstrahierende Frameworks zu benutzen.
Claymore schrieb:
> Anfänger ohne elektrotechnische
Mit der Elektronik kenne ich mich schon aus, nur will ich auch noch in
mein Hobby µC einbringen, die können mehr als nur n 40er Logik.
So viele Antworten, das kann ich nichtmal lesen!
Ich zittiere mal aus einem anderen Thread, wo es um Arduino mit ARM geht. Da haben wir nämlich ein aktuelle konkretes Beispiel zur Diskussion um HAL: "Die Takterzeugung ist aber für mich nicht überschaubar, da ich auch kein Programmierprofi bin" Das ist doch typisch. Hier hilft ihm weder die Programmiersprache noch das Arduino Framework. Spätestens jetzt muss sich der Kollege doch mit Registern auseinander setzen - unabhängig von der Programmiersprache.
... und wieder herrscht ein Glaubenskrieg der mit dem Originalthread nix zu tun hat.... Smile, eine Anfrage nach dem "richtigen" Controller und der "richtigen" Programmierung endet immer in einem endlosen Thread ... Irre ... Schönen Sonntag, Ralph
Patryk D. schrieb: > So viele Antworten, das kann ich nichtmal lesen! Warum fragst du dann so allgemein?
Stefan U. schrieb: > Wegen High-Level Programmierung versus Low-Level Programmierung: > > Ich habe Computertechnik von "unten" nach "oben" gelernt. Zuerst habe > ich mich mit Logikgattern, Speicher, ALU, Netzteilen, CRT Bildschirmen, > etc beschäftigt. Das ist soweit ja nachvollziehbar, wenn man so startet. Aber der Weg heutzutage ist doch eher umgekehrt. Die Leute kommen aus der PC-Software-Welt und kommen irgendwann auf die Idee, etwas reales zu basteln. Da macht es schon Sinn, mit High-Level einzusteigen und sich nach unten vor zu kämpfen. Ich kenne den Weg so herum, als Kind habe ich mich mehr mit Software beschäftigt und bin erst durch die formale Ausbildung über Assembler, FPGA und Halbleitertechnik auch nach ganz unten durch gekommen. Für reale Anwendungen brauche ich das aber in der Regel nicht. Da kann ich zu 90% mit einem fertigen RTOS arbeiten.
Stefan U. schrieb: > "Die Takterzeugung ist aber für mich nicht überschaubar, da ich auch > kein > Programmierprofi bin" > > Das ist doch typisch. Hier hilft ihm weder die Programmiersprache noch > das Arduino Framework. Spätestens jetzt muss sich der Kollege doch mit > Registern auseinander setzen - unabhängig von der Programmiersprache. Das ist eindeutig eine Schwäche des Frameworks und kein Problem der Methodik an sich.
Claymore schrieb: > Stefan U. schrieb: >> Zwei Befehle, von denen einer eine 1:1 Beziehung zur >> Hardware und dem Datenblatt hat. Was ist daran komliziert? Wo ist das >> Problem? > > Dass man etwas mehr machen möchte als eine LED einschalten, sollte > eigentlich logisch sein. Spätestens wenn man arithmetische Funktionen > umsetzen will, muss man sich schon tiefer mit der Architektur > beschäftigen. Es geht ja nicht darum, dass ein Anfänger gleich eine Floatingpoint-Lib in Assembler implementieren soll. Und er soll auch nicht die ersten 10 Jahre nur in Assembler programmieren. > Dass Arbeit auf Registerebene für einen Einsteiger immer eine größere > Hürde ist, habe ich ja schon mehrfach erwähnt. Das ist einer der Gründe, aus denen ich die ersten Schritte der C-Programmierung auf dem PC empfehlen würde. Da kann man sich erstmal auf die Sprache selbst konzentrieren und muss nicht gleich noch nebenher den Umgang mit Registern und den dahinterstehenden Hardware-Einheiten lernen. Ralph S. schrieb: > endet immer in einem endlosen Hm?
Falk B. schrieb: > @ ach ja doch (Gast) > >>> Arduino oder BASCOM sind für den Einstieg recht gut > >>Warum nicht LunaAVR? > > Meinetwegen auch das, ich kenn LunaAVR nicht wirklich, eigentlich nur > den Namen. Was mir daran nicht gefällt ist, daß es das Rad "neu" > erfindet. Eine Sprache, ähnlich C aber dennoch kein C. Das ist was für > Liebhaber von Exoten. Die meisten sind mit C(C++) deutlich besser > bedient, das ist Standard und dementsprechend verbreitet. Ach was, wichtig ist nicht "dem Standard" hinterherzulaufen (das machen schließlich die gefühlten 2^10 anderen Programmier-Dialekte/Varianten/Derivate, die ständig entstshen, auch nicht. Oder warum gibt es ein C ähnliches gockel-go oder die zahlreichen BASIC-Dialekte, zu denen auch BASCOM sich gesellt?! Entscheidend ist nach meinem Empfinden eine gut gepflegte Webseite mit zahlreichen Code-Beispielen und brauchbarer Dokumentation, nicht das formale, automatisiert-erzeugte Gedöns, was einem heutzutage so oft um die Ohren gehauen wird. Sondern eine Doku VOM Anwender FÜR den Anwender. Als Beispiel möchte ich hier mal die integrierte Hilfefunktion der alten DOS Borland Produkte Turbo Pascal und Turbo C++ anführen. Ein Blick und man wusste, wie etwas zu benutzen ist. Die Delhi-Webseiten beispielsweise sind diesbezüglich auch heute noch sehr gut gepflegt. Die LunaAVR Webseite erfüllt diese Anforderung ähnlich gut (jedenfalls auf den ersten Blick). Und wer sagt denn, dass man dabei bleiben MUSS und sich nicht gleichzeitig für alles andere offen halten kann? Sonst könnte man ja auch kein C# verwenden, aus Angst "dem Standard C/C++" abtrünnig zu werden. Das ist doch Unsinn. Bitte keine Denkverbote und NoGo's aussprechen. Erlaubt ist was gefällt, funktioniert und nutzt. "Spiel nicht mit den Schmuddelkindern" (BASCOM, LunaAVR) "sing nicht ihre Lieder" ... ist doch nur die alte Angst vor Konkurrenz .. Also keine Glaubenskriege befeuern, keinen Denkverboten nacheifern. Einfach vorurteilsfrei herangehen. Die Grundschule beginnt auch mit starken Vereinfachungen und nicht mit dem Stoff fürs Abitur.
> Das ist eindeutig eine Schwäche des Frameworks und > kein Problem der Methodik an sich. Patryk möchte sich mit µC beschäftigen, nach Methodik und Frameworks hat er nicht gefragt. Patryk, sag du uns doch mal, ob du dich eher mit der Hardware (Chips, Register, Bits) beschäftigen möchtest, oder mit High-Level Programmierung der Art loadFile("ftp://name:password@192.168.100.1/myFile.txt") ? Wie du siehst können wir für beides viel helfen. Nun aber alle Möglichkeiten durchzudiskutieren ohne deine Meinung einzubeziehen, bringt dich nicht wirklich weiter. Es sei denn, du wolltest genau diese Diskussion.
Rolf M. schrieb: > Es geht ja nicht darum, dass ein Anfänger gleich eine Floatingpoint-Lib > in Assembler implementieren soll. Und er soll auch nicht die ersten 10 > Jahre nur in Assembler programmieren. Nein, aber für jedes reale Projekt, was etwas mehr als nur "eine LED blinken" ist, wird Assembler sehr schnell unnötig kompliziert. Gerade für Anfänger sind solche Anwendungen ohne realen Bezug eher frustrierend, weil kein spürbarer Fortschritt erreicht ist. Unter einer realen Anwendung verstehe ich so etwas wie "einen Beschleunigungssensor über I2C auslesen, die Daten verarbeiten und die Ausgabe per USB/Ethernet/WLAN an den PC übertragen". Rolf M. schrieb: > Das ist einer der Gründe, aus denen ich die ersten Schritte der > C-Programmierung auf dem PC empfehlen würde. Da kann man sich erstmal > auf die Sprache selbst konzentrieren und muss nicht gleich noch nebenher > den Umgang mit Registern und den dahinterstehenden Hardware-Einheiten > lernen. Das ist auf jeden Fall empfehlenswert. Aber man muss ja auch nicht gleich von PC-Programmierung auf die Registerebene springen, sondern kann noch die Zwischenebene mitnehmen. Bei größeren Projekten braucht man das dann sowieso.
> Gerade für Anfänger sind solche Anwendungen ohne realen > Bezug eher frustrierend, weil kein spürbarer Fortschritt > erreicht ist. Du hast übersehen, dass ich ganz weit oben auf ein Assembler Tutorial verlinkt habe, welches Schritt für Schritt mit einem popeligen ATtiny13 ein elektronisches Spiel entwickelt. Jede einzelne Codezeile ist erklärt und immer wieder verweise ich auf das Datenblatt - damit man das Arbeiten mit Datenblättern lernt. Fortschritt ist da alle paar Minuten spürbar und es ist auch eine reale Anwendung, die in den 80er Jahren sogar Millionenfach verkauft wurde und sogar heute noch als Handy-App wieder vermarketet wird. Tu mal nicht so, als gäbe es keinen geeigneten Anwendungsfall, um frühzeitig ein bisschen Assembler zu lernen. Ich rate ja auch keineswegs dazu, bei Assembler zu bleiben. Ich rate auch nicht dazu, mit Assembler anzufangen. Nur ein bisschen Assembler (nicht mehr) nebenbei zu lernen, kann nicht verkehrt sein.
Wolfgang schrieb: > Schon wenn man einfach nur mal > einen kurzen Puls auf einem Pin erzeugen will, ist man mit dem ach so > tollen Abstraktionslevel am Ende. Da ist es schon sehr hilfreich, wenn > nicht schon bei digitalWrite() der Horizont kommt, sondern man noch > etwas mehr vom System weiß. Es hindert Dich niemand daran, Deine Kenntnisse zu vertiefen und beispielsweise die Libs aufzubohren, abgesehen davon, dass es auch auf diesem level lösbar wäre. Ihr solltet davon abkommen, dass die hier aufschlagenden Arduino-Frager den Durchschnitt der Arduinonutzer darstellen. Das sind sie eher nicht. Genausowenig wie die BASCOM, C, C++, ... Frager den Durchschnitt der Programmierer dieser Sprachen repräsentieren.
@ ach ja doch (Gast) >>>Warum nicht LunaAVR? >> Liebhaber von Exoten. Die meisten sind mit C(C++) deutlich besser >> bedient, das ist Standard und dementsprechend verbreitet. >Ach was, wichtig ist nicht "dem Standard" hinterherzulaufen (das machen >schließlich die gefühlten 2^10 anderen >Programmier-Dialekte/Varianten/Derivate, die ständig entstshen, auch >nicht. Auch DU tust das, indem du DEUTSCH oder ENGLISCH sprichst! Das sprechen auch Millionen von Menschen. Und es hat so seine Vorteile, wenn man die gleich Sprache spricht. > Oder warum gibt es ein C ähnliches gockel-go oder die zahlreichen >BASIC-Dialekte, zu denen auch BASCOM sich gesellt?! Weil es Leute gab, die mal ein wenig experimentieren wollen und ihre eigene Sprache/Dialekt kreieren wollten. Ist vollkommen OK und manchmal bekommt der Rest der Welt dadurch neue Erkenntnisse. Manchmal ensteht aber auch nur wieder der 1001. Dialekt. Willkommen in Babylon ;-) >Entscheidend ist nach meinem Empfinden eine gut gepflegte Webseite mit >zahlreichen Code-Beispielen und brauchbarer Dokumentation, Sag doch einfach, daß du ein LunaAVR Fan bist, das verküzt die Diskussion ;-) > nicht das >formale, automatisiert-erzeugte Gedöns, was einem heutzutage so oft um >die Ohren gehauen wird. Sondern eine Doku VOM Anwender FÜR den Anwender. Dumm nur, wenn die meisten schreibenden Anwender kein besonders hohen Niveau bzw. Talent zum Doku-Schreiben haben. >den ersten Blick). Und wer sagt denn, dass man dabei bleiben MUSS und >sich nicht gleichzeitig für alles andere offen halten kann? Ich lerne doch nicht Portugiesisch wenn die große Masse in Südamerika Spanisch spricht, auch wenn das recht ähnlich ist. > Sonst könnte >man ja auch kein C# verwenden, aus Angst "dem Standard C/C++" abtrünnig >zu werden. Das ist doch Unsinn. Von Angst sprach hier keiner. Aber die Grundlage von C# ist immer noch C (denke ich mal, hab C# nie angeschaut) >Bitte keine Denkverbote und NoGo's aussprechen. Bitte? Es war eine EMPFEHLUNG bzw. MEINUNG! > Erlaubt ist was gefällt, >funktioniert und nutzt. "Spiel nicht mit den Schmuddelkindern" (BASCOM, >LunaAVR) "sing nicht ihre Lieder" ... ist doch nur die alte Angst vor >Konkurrenz .. Das mit dem sinnerfassenden Lesen solltest du noch mal üben. >Einfach vorurteilsfrei herangehen. Die Grundschule beginnt auch mit >starken Vereinfachungen und nicht mit dem Stoff fürs Abitur. Eben, darum ist ASM kein sonderlich guter Einstieg in die Programmierung. Das war nur früher so, als das Thema nur von eingefleischten Freaks beackert wurde und C und höhere Sprachen kaum zur Verfügung standen, zumindest nicht kostenfrei.
Langer Rede kurzer Sinn: Da du bereits mit Logikgattern gearbeitet hast, kaufe Dir ein Arduino Nano Board und schau mal, was man damit so machen kann. Ein paar Bauteile für drumherum hast du sicher schon. Kannst ja mit einer LED anfangen. Du kannst damit zahlreiche Programmiersprachen ausprobieren und musst nur Euro investieren. Und wenn du merkst, dass du viel größeres Sachen machen willst, als dieser kleine µC kann, dann schmeiß ihn weg und hole Dir ein STM32 Discovery Board oder irgendein anderes ARM basiertes Board mit integrierter USB Programmierschnittstelle. Denn auch die sind so billig, dass man da kaum etwas falsch machen kann.
Stefan U. schrieb: > Fortschritt ist da alle paar Minuten spürbar und es ist auch eine reale > Anwendung, die in den 80er Jahren sogar Millionenfach verkauft wurde und > sogar heute noch als Handy-App wieder vermarketet wird. Etwas nachzubauen hat nichts mit Fortschritt zu tun. Klar kann man so lernen, aber da braucht man schon eine Menge Ausdauer, bis man in der Lage ist, selbst etwas eigenes zu entwickeln. Das schnelle Erfolgserlebnis ist die Grundlage des Erfolgs von Arduino und hat sicherlich viele tausende zu Microcontrollern gebracht. Leute, die Assembler sofort abgeschreckt hätte. Für den Möchtegern-Foren-Profi mag das frustrierend sein, weil sie nun nicht mehr zu einem exklusiven Club gehören und da muss man sich immer wieder mit Sätzen wie "ohne Assembler hat man keine Ahnung, was man wirklich tut" und ähnliches verteidigen. Das ist irgendwie schade. Stefan U. schrieb: > Ich rate ja auch keineswegs dazu, bei Assembler zu bleiben. Ich rate > auch nicht dazu, mit Assembler anzufangen. Nur ein bisschen Assembler > (nicht mehr) nebenbei zu lernen, kann nicht verkehrt sein. Man braucht Assembler heute aber in aller Regel gar nicht mehr. Von daher ist der Vorschlag für einen Anfänger einfach sinnlos.
>> ein bisschen Assembler nebenbei zu lernen, kann nicht verkehrt sein. > Man braucht Assembler heute aber in aller Regel gar nicht mehr. > Von daher ist der Vorschlag für einen Anfänger einfach sinnlos. Aber mit STM32 anzufangen hälst du für Sinnvoll. Komische Welt das ist. Ich bin wohl zu alt. > Etwas nachzubauen hat nichts mit Fortschritt zu tun. Es ging um Lernfortschritt, nicht darum, die Menschheit weiter zu entwickeln. Es ging darum, dass man beim Lernen voran kommt und Zwischenergebnisse sehen kann.
Stefan U. schrieb: > Aber mit STM32 anzufangen hälst du für Sinnvoll. Komische Welt das ist. > Ich bin wohl zu alt. Ich schlage vor, mit High-Level anzufangen. Die darunter liegende Plattform spielt da keine größere Rolle. Stefan U. schrieb: > Es ging um Lernfortschritt, nicht darum, die Menschheit weiter zu > entwickeln. Es ging darum, dass man beim Lernen voran kommt und > Zwischenergebnisse sehen kann. Den meisten Bastlern geht es aber eher um reale Ergebnisse als um den Lernerfolg.
@Claymore ...man könnte denken Du bist Politiker, versuchst auf biegen und brechen die Leute von Deiner Meinung zu überzeugen. "Assembler braucht man in aller Regel garnicht mehr"....Du hast ja richtig Ahnung, eben wie ein Politiker mit seinen viel zitieren "Fachkräften und Spezialisten". Solche Diskussionen gibt es zu Hauf und letztendlich enden sie mit der Erkenntnis das die Programmiersprache egal ist und eher der Zweck die Sprache bestimmt. Auch als Anfänger bestimmt der Zweck die zu erlernende Programmiersprache, wobei der TO sich hier am wenigsten zu Wort meldet und sich nur berieseln lässt. Spontan würde ich deshalb den TO auch zu der Arduino-Ecke mit samt seiner putzigen Programmierumgebung raten, da man dort mit super wenig Anstrengung relativ nette Ergebnisse erzielen kann, also genau ein passendes Ebenbild zu seinem Interesse :)
Bestromer schrieb: > @Claymore > ...man könnte denken Du bist Politiker, versuchst auf biegen und brechen > die Leute von Deiner Meinung zu überzeugen. > "Assembler braucht man in aller Regel garnicht mehr"....Du hast ja > richtig Ahnung, eben wie ein Politiker mit seinen viel zitieren > "Fachkräften und Spezialisten". Wenn die sachlichen Argumente ausgehen, wird es persönlich. Das ist die übliche Masche. Bestromer schrieb: > Spontan würde ich deshalb den TO auch zu der Arduino-Ecke mit samt > seiner putzigen Programmierumgebung raten, da man dort mit super wenig > Anstrengung relativ nette Ergebnisse erzielen kann, also genau ein > passendes Ebenbild zu seinem Interesse :) Das ist auch wieder typisch für solche Pseudo-Experten. Wer leicht Ergebnisse erreichen will ist ein Pfuscher, ein richtiger Experte müsse ja die höchst mögliche Anstrengung in Kauf nehmen, sonst könne man ja nichts. Und so weiter und so fort.
google schrieb: > Es hindert Dich niemand daran, Deine Kenntnisse zu vertiefen und > beispielsweise die Libs aufzubohren, abgesehen davon, dass es auch auf > diesem level lösbar wäre. Genau dafür muss der Horizont über digitalWrite() hinaus reichen und es ist gut, sich im Controller Datenblatt mal anzusehen, was da alles an einem einzelnen Pin an Registern dran hängt. Sonst heißt es schnell, "der ... kann das nicht" oder - um bei dem Beispiel zu bleiben - man braucht einen 200MHz Prozessor, um einen 1µs Puls zu erzeugen.
Claymore schrieb: > Wenn die sachlichen Argumente ausgehen, wird es persönlich. Das ist > die übliche Masche. ...ja, ich hab die Dinge beim Namen genannt, allerdings gehen hier keine Argumente aus, es entwickelt sich eben nur in eine Richtung...Monologe braucht hier keiner.... > Bestromer schrieb: >> Spontan würde ich deshalb den TO auch zu der Arduino-Ecke mit samt >> seiner putzigen Programmierumgebung raten, da man dort mit super wenig >> Anstrengung relativ nette Ergebnisse erzielen kann, also genau ein >> passendes Ebenbild zu seinem Interesse :) > > Das ist auch wieder typisch für solche Pseudo-Experten. Wie war das nochmal mit dem persönlich werden? Willkommen auf der selben Ebene....zudem pauschalisieren wir noch?
Bestromer schrieb: > ...all das hilft aber dem TO nicht weiter... Ich denke mal, der ist schon raus. Patryk D. schrieb: > So viele Antworten, das kann ich nichtmal lesen!
google schrieb: > Ich denke mal, der ist schon raus. ...das denke ich auch :) Schade das ein eigentlich so interessanter Thread immer in einem Glaubenskrieg enden muss...liegt aber wahrscheinlich in der Natur der Menschen :o)
Wolfgang schrieb: > Genau dafür muss der Horizont über digitalWrite() hinaus reichen Zunächst muss sein Interesse darüber hinaus reichen. Dann liest er nach oder fragt. Wenn er hier fragt, wird es wohl etwas schwerer, denn er ist per ungeschriebener Foren-Definition ein Aussätziger, denn man beschimpft und auslacht. Nur die Harten (das sind meist eher die Lernresistenten) bleiben am Ball. Und nur wenige Leute mit Knowhow erbarmen sich zu einer vernünftigen Antwort, auch die nicht immer frei von Häme und Arroganz.
Falk B. schrieb: > @ ach ja doch (Gast) > >>>>Warum nicht LunaAVR? >>> Liebhaber von Exoten. Die meisten sind mit C(C++) deutlich besser >>> bedient, das ist Standard und dementsprechend verbreitet. > >>Ach was, wichtig ist nicht "dem Standard" hinterherzulaufen (das machen >>schließlich die gefühlten 2^10 anderen >>Programmier-Dialekte/Varianten/Derivate, die ständig entstshen, auch >>nicht. > > Auch DU tust das, indem du DEUTSCH oder ENGLISCH sprichst! Das sprechen > auch Millionen von Menschen. Und es hat so seine Vorteile, wenn man die > gleich Sprache spricht. Nicht Vergleichbar, weil Alltagskommunikation etwas ganz anderes darstellt als SPEZIALISIERTE Programmierdialekte. Mit der Alltagssprache werden Gefühle ausgetauscht. Mit ein paar Quellcodezeilen eher nicht (gar nicht). >> Oder warum gibt es ein C ähnliches gockel-go oder die zahlreichen >>BASIC-Dialekte, zu denen auch BASCOM sich gesellt?! > > Weil es Leute gab, die mal ein wenig experimentieren wollen und ihre > eigene Sprache/Dialekt kreieren wollten. Ist vollkommen OK und manchmal > bekommt der Rest der Welt dadurch neue Erkenntnisse. Manchmal ensteht > aber auch nur wieder der 1001. Dialekt. Willkommen in Babylon ;-) Dieses "Experimentieren" von "ein paar Leuten" gibt es. Das trifft aber auf große Neuentwicklungen der letzten Jahre wie C#, Google go, Rust und wie sie alle heißen bei weitem nicht mehr zu. Dahinter stehen Weltkonzerne und hunderttausende bzw. Millionen interessierte Nutzer. Warum ist das so, wenn doch alle mit C,C++ vorlieb nehmen könnten?! Anscheinend deckt C/C++ nicht (mehr) die Erwartungen ab, die man glaubt, in den Neuentwicklungen zu finden. >>Entscheidend ist nach meinem Empfinden eine gut gepflegte Webseite mit >>zahlreichen Code-Beispielen und brauchbarer Dokumentation, > > Sag doch einfach, daß du ein LunaAVR Fan bist, das verküzt die > Diskussion ;-) Ich muss bekennen, ich selber habe praktisch noch nichts mit LunaAVR gemacht (nur dort herumgestöbert). Ich brauche es auch nicht unbedingt, weil ich auch gut mit C zurechtkomme. Aber mir gefallen eben Webseiten wie die von LunaAVR, wo ich das Gefühl habe, hier steckt jemand richtig Arbeit hinein und kümmert sich. Mir gefallen diese "Old-School" Webseiten im Gegensatz zu denen, die zwar in font >96px in Riesenlettern Werbung betreiben, wo ich dann aber erst mal mühsam den Einstieg suchen muss, weil gerade mal 2 Beispiele vorhanden sind und mehr nicht. Was mir an LunaAVR übrigens weniger gut gefällt ist deren Lizenz Modell, also diese Monats oder Jahreslizenzen. Aber das muss einen beim Einstieg erst mal auch nicht unbedingt kümmern. Ist ja keine Ehe, die man da eingeht. ;) Was mir auch nicht sonderlich gefällt ist die Zwangsanmeldung, um im Forum zu lesen. Das sollten sie dort mal ändern. Das wirkt zu abweisend. >> nicht das >>formale, automatisiert-erzeugte Gedöns, was einem heutzutage so oft um >>die Ohren gehauen wird. Sondern eine Doku VOM Anwender FÜR den Anwender. > > Dumm nur, wenn die meisten schreibenden Anwender kein besonders hohen > Niveau bzw. Talent zum Doku-Schreiben haben. Es muss ja nicht in schönster Prosa verfasst sein. Einfach so, dass es einladend, animierend zum SOFORT anfangen wirkt. Mal als Beispiel so wie hier http://www.delphi-treff.de/ Die Delphi-Treff Webseite ist diesbezüglich einfach schön gestaltet. >> Sonst könnte >>man ja auch kein C# verwenden, aus Angst "dem Standard C/C++" abtrünnig >>zu werden. Das ist doch Unsinn. > > Von Angst sprach hier keiner. Aber die Grundlage von C# ist immer noch C > (denke ich mal, hab C# nie angeschaut) Ich bin nicht genug Experte oder "Erklärbar" für Details und Hintergründe der Entwicklung solcher Dialekte. In C# steckt C/C++, Java, Delphi drin (Anders Hejlsberg) und C# hat sich über die Jahre beträchtlich gemausert. Für den Einsteiger ist nach meiner Auffassung wichtiger, ob er ein positives Gefühl beim Herantasten entwickelt oder ob's in Quälerei ausartet und damit abschreckend wirkt. Wie schnell stellen sich Erfolge ein? Das ist die entscheidende Frage (vorausgesetzt man kann selber entscheiden und muss nicht ..). Ohne Lust nur Frust und das gilt es zu vermeiden. Der eine ist Pragmatiker, will nur das es läuft. Der andere möchte allumfassendes Expertenwissen. Der eine akzeptiert nur OpenSource. Anderen ist nur wichtig, dass die Tools privat frei verwendbar sind. Manche geben auch gerne mal Geld für Software aus wie so was hier http://shop.myavr.de/index.php?sp=artlist_kat.sp.php&katID=7 und werden damit glücklich. Jeder wie er kann und will. >>Bitte keine Denkverbote und NoGo's aussprechen. > > Bitte? Es war eine EMPFEHLUNG bzw. MEINUNG! Ich gab auch nur meine Meinung hinzu. Gerade bei LunaAVR kommt aber gerne der "warnende Reflex" von irgend jemand, der bei vielem anderen was so genannt wird komischerweise unterbleibt. Ist mir jedenfalls schon aufgefallen. Als C# aufkam waren die warnenden Reflexe ja auch nicht gerade selten. Du wirst es wissen. Wer will schon wissen, wie sich alles entwickelt. Wir wissen ja nicht mal wer uns am Jahresende 2016 noch regiert (kleine neckische Randbemerkung). ;-) >>Einfach vorurteilsfrei herangehen. Die Grundschule beginnt auch mit >>starken Vereinfachungen und nicht mit dem Stoff fürs Abitur. > > Eben, darum ist ASM kein sonderlich guter Einstieg in die > Programmierung. Das war nur früher so, als das Thema nur von > eingefleischten Freaks beackert wurde und C und höhere Sprachen kaum zur > Verfügung standen, zumindest nicht kostenfrei. Ich würde das nicht so verallgemeinern. Ich glaube da kommt man schon selber drauf was einem liegt oder auch nicht, einfach in dem man die Dinge mal "anfasst".
Vielleicht liest der TE das ja noch. Ich bin vor kurzem von Arduino auf STM32 umgestiegen. Mein Tipp an dich: Lies dich erstmal ein wie uC funktionieren. Ich kann komplett verstehen, wie du gerade fühlst. Das Problem ist, dass die Frage nach einem uC von sehr vielen Sachen abhängt, die du logischerweise nicht wissen kannst. Auch wenn hier viele raten Assembler, GCC etc. da denkst du jetzt sicher omg, wo soll ich da anfangen??? Folge meinem Tipp. Fange zB hier an: http://www.eastaughs.fsnet.co.uk/cpu/structure-index.htm Eigentlich funktionieren alle uC etwa gleich. Du wirst schnell selber merken, was du wissen musst und was am Anfang nicht so wichtig ist. Zu Beginn ist es einfach gut, über viele Begriffe ein Halbwissen zu haben. Ja ein Halbwissen!! Du willst ja nicht Professor an ner Uni werden. Viel Glück und lass dich hier nicht runtermachen. Hier hat jeder mal klein angefangen. Gruss Felix
@ ach ja doch (Gast) >> Auch DU tust das, indem du DEUTSCH oder ENGLISCH sprichst! Das sprechen >> auch Millionen von Menschen. Und es hat so seine Vorteile, wenn man die >> gleich Sprache spricht. >Nicht Vergleichbar, Aber sicher! >weil Alltagskommunikation etwas ganz anderes >darstellt als SPEZIALISIERTE Programmierdialekte. Mit der Alltagssprache >werden Gefühle ausgetauscht. Bist du eine Frau? Nein, auch mit Alltagskommunikation werden harte FAKTEN und INFORMATIONEN ausgetauscht. > Mit ein paar Quellcodezeilen eher nicht >(gar nicht). love_me(tender); ;-) >Dieses "Experimentieren" von "ein paar Leuten" gibt es. Das trifft aber >auf große Neuentwicklungen der letzten Jahre wie C#, Google go, Rust und >wie sie alle heißen bei weitem nicht mehr zu. Dahinter stehen >Weltkonzerne und hunderttausende bzw. Millionen interessierte Nutzer. Die Millionen von Nutzern kommen erst danach. >Warum ist das so, wenn doch alle mit C,C++ vorlieb nehmen könnten?! >Anscheinend deckt C/C++ nicht (mehr) die Erwartungen ab, die man glaubt, >in den Neuentwicklungen zu finden. Niemand hat behauptet, daß C/C++ ALLES abdecken kann und für immer und ewig das Allein selig Machende ist! Aber es ist halt SEHR weit verbreitet und für viele (nicht alle!) Aufgaben nutzbar! >Ich muss bekennen, ich selber habe praktisch noch nichts mit LunaAVR >gemacht (nur dort herumgestöbert). Ich brauche es auch nicht unbedingt, >weil ich auch gut mit C zurechtkomme. Aber mir gefallen eben Webseiten >wie die von LunaAVR, wo ich das Gefühl habe, hier steckt jemand richtig >Arbeit hinein und kümmert sich. Also doch Frau. Denn das Gefühl kann schon mal täuschen, wenn sich jenseits der netten Verpackung (schicke Website) in der Realität dann doch ein paar unschöne Dinge auftun. Ob das bei LunaAVR so ist weiß ich nicht! >Mir gefallen diese "Old-School" >Webseiten im Gegensatz zu denen, die zwar in font >96px in Riesenlettern >Werbung betreiben, wo ich dann aber erst mal mühsam den Einstieg suchen >muss, weil gerade mal 2 Beispiele vorhanden sind und mehr nicht. Das ist nett, hat mit der Eignung der Programmiersprache aber recht wenig zu tun. >> Dumm nur, wenn die meisten schreibenden Anwender kein besonders hohen >> Niveau bzw. Talent zum Doku-Schreiben haben. >Es muss ja nicht in schönster Prosa verfasst sein. Einfach so, dass es >einladend, animierend zum SOFORT anfangen wirkt. Auch das können eher weniger Leute. >Für den Einsteiger ist nach meiner Auffassung wichtiger, ob er ein >positives Gefühl beim Herantasten entwickelt oder ob's in Quälerei >ausartet und damit abschreckend wirkt. Stimmt! ;-) >Wie schnell stellen sich Erfolge >ein? Das ist die entscheidende Frage (vorausgesetzt man kann selber >entscheiden und muss nicht ..). Ohne Lust nur Frust und das gilt es zu >vermeiden. Der eine ist Pragmatiker, will nur das es läuft. Der andere >möchte allumfassendes Expertenwissen. Das will kein Anfänger. > Der eine akzeptiert nur >OpenSource. Auch so eine Religion. >>>Bitte keine Denkverbote und NoGo's aussprechen. >> Bitte? Es war eine EMPFEHLUNG bzw. MEINUNG! >Ich gab auch nur meine Meinung hinzu. FALSCH! Du hast von Denkverboten gesprochen, die nie da waren! > Gerade bei LunaAVR kommt aber >gerne der "warnende Reflex" von irgend jemand, der bei vielem anderen >was so genannt wird komischerweise unterbleibt. Ich habe das begründet. > Ist mir jedenfalls schon >aufgefallen. Als C# aufkam waren die warnenden Reflexe ja auch nicht >gerade selten. Logisch, weil eine neue Sau durchs Dorf getrieben wurde. Hat jemand eine brauchbare Zusammenfassung/Bewertung der Vorteile von C#? > Du wirst es wissen. Wer will schon wissen, wie sich alles >entwickelt. Wir wissen ja nicht mal wer uns am Jahresende 2016 noch >regiert (kleine neckische Randbemerkung). ;-) Sehr schön! Dafür würde ich dir glatt 3 "sehr lesenswert" geben wollen! (es kann nur besser werden!)
Falk B. schrieb: > Bist du eine Frau? Jetzt bin ich geschockt.... Obwohl männlich, tausche ich doch über die Sprache Gefühle und Emotionen aus. Auch sehe ich das dieses hier im Forum dauernd passiert. Jede Frage, jede Antwort, beinhaltet auch eine soziale Komponente. Evtl. solltest du das nochmal überdenken....
Lothar M. schrieb: > Natürlich ist es unsinnig, auf einem ARM mit Assembler anzufangen Warum? Zum Anfang ein Pin setzen oder löschen geht in ARM Assembler nicht schwieriger als in 8051 oder AVR Assembler, nur anders. Das hier ist für ARM11 aber Cortex M ist nicht anders: http://kampis-elektroecke.de/?page_id=4620 Lothar M. schrieb: > Beim ARM ist schon der Interruptcontroller komplexer als ein alter 8051 > oder ein kleiner AVR Wie wäre dann ein Einstieg mit einem modernen 8051 z.B. EFM8BB31 entspricht ATMEGA328 kostet aber nur 1/3 und Debugger kostet nur 25 EUR und Keil Compiler ist für umsonst.
@Ulrich F. (combie) >> Bist du eine Frau? >Jetzt bin ich geschockt.... Wirklich? >Obwohl männlich, tausche ich doch über die Sprache Gefühle und Emotionen >aus. >Auch sehe ich das dieses hier im Forum dauernd passiert. Siccher, aber nicht NUR! >Jede Frage, jede Antwort, beinhaltet auch eine soziale Komponente. In der Tat. >Evtl. solltest du das nochmal überdenken.... Nö. ;-)
Autor: Bestromer (Gast) Datum: 24.01.2016 13:56 Claymore schrieb: >> Wenn die sachlichen Argumente ausgehen, wird es persönlich. Das ist >> die übliche Masche. >Wie war das nochmal mit dem persönlich werden? Willkommen auf der selben >Ebene....zudem pauschalisieren wir noch? Im A&B-Forum reitet Claymore auf ähnlich hohem Roß mit guten Ratschlägen daher. Allerdings ist er dort noch zusätzlich Millionär, erfolgreicher Unternehmer und Börsenprofi.
Hi, Ihr seid doch alle nicht ganz dicht mit Eurer Diskussion. Einem Anfänger ARM und Assembler zu empfehlen ist auch völlig durchgeknallt. Ansonsten hab ich mir den ganzen Sermon ab der Hälfte gar nicht mehr durchgelesen. Ich beschreibe mal, wie ich dazu gekommen bin und ich denke ich habe von geringen Bastlerkenntnissen (Schaltungen aus Zeitschriften nachbauen ohne sie zu verstehen) inzwischen zumindest sehr fortgeschrittenes Bastlerniveau erreicht. Vorher nur Basic und Pascal irgendwann mal in der Schule gelernt, habe ich mit C-Control angefangen, als das noch recht neu war. Simples Basic und man hat schnell viele lustige Dinge damit erreicht. Daß das Ding damals alle 1-2ms einen Basic-Befehl abgearbeitet hat, war beeindruckend ;-) (Basic Interpreter auf dem antiken µC). Das hat Lust auf mehr gemacht und ich bin auf AVR und Bascom umgestiegen. Der Einstieg fällt sehr leicht und wenn man sich weiterentwickeln will geht das in Bascom sehr gut. Zuerst kann man die eingebauten Goodies nutzen, also Config Timer, Input (serielles Byte einlesen) usw. Da weiß man nicht unbedingt was im Hintergrund passiert aber für die meisten Dinge tut das durchaus. Input wartet eben, bis das Byte da ist und das Programm macht bis dahin nichts. Will man mehr, geht man eben auf Register-Ebene und hat die volle Kontrolle. Die Uart per Int auslesen ist dann auch kein Problem mehr, genauso wie alles Andere, was man auch in C oder Assembler machen könnte. Dafür muß man aber eben das Datenblatt studieren (lesen ist nicht das richtige Wort) und verstehen. Bei C hat man diese Einstiegshilfen nicht und muß bei viel mehr Dingen gleich ins kalte Wasser springen. Mal ganz abgesehen von der völlig kranken Syntax. Immer wieder diese Fragen zur Bytemanupilation. Wenn ich in Bascom ein Bit in einem Register setzen will, dann schreibe ich "Register.Bit = 1". Bascom macht daraus genau das Gleiche wie das kryptische Kauderwelsch in C. Wenn gewünscht, kann man dann immer noch auf C umsteigen, denn das Programmieren folgt der selben Logik. Die Syntax ist eben nur sehr anders und man muß eben C lernen. Bascom ist dagegen fast selbsterklärend und sehr intuitiv. Es kommt aber auch sehr darauf an, was man vorhat und nicht zuletzt wie alt man ist. Mit Anfang 20 würde ich tunlichst C lernen (und das sage ich als Bascom-Jünger). Das ist nunmal der Standard. Erst recht, wenn man es mal beruflich damit zu tun bekommen könnte. Bascom ist dabei aber keine Zeitverschwendung denn wie gesagt, das Prinzip des µC-Programmierens ist letztendlich das Gleiche. Mit mittlerweile Mitte 40 und nur Bastelambitionen kann man es aber auch bei Bascom belassen. Ich programmiere zwar beruflich noch etwas aber den Kollegen die in C schreiben kann ich sowieso nicht mehr das Wasser reichen wenn ich jetzt C lerne. Da konzentriere ich mich lieber auf das, was ich besser kann. Daß Bascom für mehr als ein paar blinkende LEDs oder einen Schrittmotor gut ist zeigt z.B. der Treiber, den ein Forumsmitglied im Bascom-Forum für ein 320x240 TFT mit 262k Farben und Touch geschrieben hat. Der ATMega befeuert das Display mit 8MHz SPI. Ich hab den Kram hier und das ist flott. Da ist allerdings auch etwas Inline Assembler dabei. In C wäre das aber vermutlich nicht anders. 8MHz SPI bei 16MHz Takt macht nur Sinn, wenn man sich ganz tief in den Maschinenraum begibt. Das ist aber ein Level, das ich nicht mehr verstehen muß. Ich sehe nur nach, welche Ressourcen der Treiber belegt. Gruß, Norbert
Norbert S. schrieb: > Der ATMega befeuert das Display mit 8MHz SPI. > Ich hab den Kram hier und das ist flott. > Da ist allerdings auch etwas Inline Assembler dabei. Ja und? Ich habe kürzlich den AVR Treiber für ein TFT mit ST7735R auf ARM "portiert": LPC810 DIP-8. War fast nichts zu tun, nur die wenigen Stellen Inline Assembler durch C ersetzen, lief sofort. Natürlich könnte man es nun schneller machen durch Ersetzen der ganzen chars und shorts durch longs und für die Bitmanipulationen könnte man mit ARM Inline Assembler anrücken, aber was solls.
Lothar schrieb: > Norbert S. schrieb: >> Der ATMega befeuert das Display mit 8MHz SPI. >> Ich hab den Kram hier und das ist flott. >> Da ist allerdings auch etwas Inline Assembler dabei. > > Ja und? Ich habe kürzlich den AVR Treiber für ein TFT mit ST7735R auf > ARM "portiert": LPC810 DIP-8. War fast nichts zu tun, nur die wenigen > Stellen Inline Assembler durch C ersetzen, lief sofort. Natürlich könnte > man es nun schneller machen durch Ersetzen der ganzen chars und shorts > durch longs und für die Bitmanipulationen könnte man mit ARM Inline > Assembler anrücken, aber was solls. Und du meinst im Ernst, daß das die geeignete Einstellung ist, einem Neueinsteiger die µC schmackhaft zu machen? Denn genau darum gehts in diesem Thread. Und nicht die Selbstbeweihräucherung, was man doch für ein toller Hecht ist... Ein Anfänger will überhaupt erstmal die Grundlagen lernen! Das hast du scheinbar nicht bedacht!
Lothar schrieb: > Norbert S. schrieb: >> Der ATMega befeuert das Display mit 8MHz SPI. >> Ich hab den Kram hier und das ist flott. >> Da ist allerdings auch etwas Inline Assembler dabei. > > Ja und? Ich habe kürzlich den AVR Treiber für ein TFT mit ST7735R auf > ARM "portiert": LPC810 DIP-8. War fast nichts zu tun, nur die wenigen > Stellen Inline Assembler durch C ersetzen, lief sofort. Natürlich könnte > man es nun schneller machen durch Ersetzen der ganzen chars und shorts > durch longs und für die Bitmanipulationen könnte man mit ARM Inline > Assembler anrücken, aber was solls. Hi, Oho, ein ARM kann also so ein Display ansteuern. Wäre "ARM" wenn nicht... Ich wollte damit doch nur zeigen, daß man mit Bascom einen AVR-8Bit durchaus bis an die Grenze der Hardware ausreizen kann. Auf ARM potieren kann man die Software allerdings nicht so einfach - mangels Compiler... Gruß, Norbert
asdf schrieb: > Und du meinst im Ernst, daß das die geeignete Einstellung ist, einem > Neueinsteiger die µC schmackhaft zu machen? Denn genau darum gehts in > diesem Thread. Und nicht die Selbstbeweihräucherung, was man doch für > ein toller Hecht ist... > Ein Anfänger will überhaupt erstmal die Grundlagen lernen! Das hast du > scheinbar nicht bedacht! Danke! Das nützt dem n00b nämlich mal gar nichts. Gruß, Norbert
Norbert S. schrieb: > asdf schrieb: >> Und du meinst im Ernst, daß das die geeignete Einstellung ist, einem >> Neueinsteiger die µC schmackhaft zu machen? Denn genau darum gehts in >> diesem Thread. Und nicht die Selbstbeweihräucherung, was man doch für >> ein toller Hecht ist... >> Ein Anfänger will überhaupt erstmal die Grundlagen lernen! Das hast du >> scheinbar nicht bedacht! > > Danke! Das nützt dem n00b nämlich mal gar nichts. > > Gruß, > Norbert Aber die Aussage von Lothar "Ätsch, ich kann einen AVR-Treiber auf ARM portieren" ist wohl viel nützlicher, oder? ;-)
asdf schrieb: > Und nicht die Selbstbeweihräucherung, was man doch für > ein toller Hecht ist... Hatte keine Ahnung was der AVR TFT Treiber genau macht und habe mich selbst gewundert, dass der fast ohne Änderungen auf einem LPC ARM lief. > einem Neueinsteiger die µC schmackhaft zu machen Wenn es wie ich ein Neueinsteiger ist der bereits auf dem PC in C programmiert hat ist es wohl anders als wenn jemand mit uC anfängt und zum ersten Mal programmiert. Ich habe jedenfalls nicht mit uC angefangen indem ich Datenblätter und Tutorials durchgearbeitet habe, sondern habe Demos vom Hersteller auseinander genommen, in die Library Funktionen reingeschaut welche Register genutzt werden und erst dann im Datenblatt nachgesehen, was die Bits bedeuten.
Norbert S. schrieb: > Auf ARM potieren kann man die Software allerdings nicht so einfach - > mangels Compiler... http://hackaday.com/2012/09/20/programming-an-arm-with-basic/ https://www.riscosopen.org/content/sales/risc-os-pico
asdf schrieb: > Das hast du scheinbar nicht bedacht! Es können sich offenbar einige nicht mehr dran erinnern, wie sie angefangen haben. Wenn mir damals einer einen 32-Bit STM32 vor den Latz geknallt und gesagt hätte "Fang mit dem an. Das ist einfach!", dann würde ich heute was anderes machen...
Lothar schrieb: > Ich habe jedenfalls nicht mit uC angefangen indem ich Datenblätter und > Tutorials durchgearbeitet habe, sondern habe Demos vom Hersteller > auseinander genommen, in die Library Funktionen reingeschaut welche > Register genutzt werden und erst dann im Datenblatt nachgesehen, was die > Bits bedeuten. Das klingt doch schon ganz anders :-)
Lothar schrieb: > Hatte keine Ahnung was der AVR TFT Treiber genau macht und habe mich > selbst gewundert, dass der fast ohne Änderungen auf einem LPC ARM lief. Der schlimmste Zustand einer Entwicklung ist, wenn es funktioniert, aber der Entwickler selbst nicht weiß, warum es funktioniert... ;)
:
Bearbeitet durch User
Lothar M. schrieb: > asdf schrieb: >> Das hast du scheinbar nicht bedacht! > Es können sich offenbar einige nicht mehr dran erinnern, wie sie > angefangen haben. Wenn mir damals einer einen 32-Bit STM32 vor den > Latz geknallt und gesagt hätte "Fang mit dem an. Das ist einfach!", dann > würde ich heute was anderes machen... Wohl wahr. Bei mir war es C-Control, heute wäre das wohl Arduino. Gruß, Norbert
Thomas E. schrieb: > Der schlimmste Zustand einer Entwicklung ist, wenn es funktioniert, aber > der Entwickler selbst nicht weiß, warum es funktioniert... ;) Wenn Du in Windows oder Embedded Linux oder Arduino oder Atmel ASF oder CMSIS eine Funktion nutzt, weisst Du dann genau, was die tut, wie die Abhängigkeiten sind, und ob die angegebenen Wertebereiche wirklich stimmen? Ich habe hier grade einen LPC ARM bei dem ging der externe Gruppen Interrupt nicht, und ich musste dann feststellen, dass im CMSIS Include die Enable Register Adresse falsch aus dem Manual abgeschrieben war.
Prügelvereinsvorsitzender schrieb: > der arme nOOb, jetzt hat er den Durchblick.. Jo, falsche Frage am falschen Ort gestellt. n00b, nimm Arduino oder Bascom, mit entsprechendem Starterkit. Kein Selbstgefrickel sondern eine Fertiglösung mit Programmer oder Bootloader. Am Anfang muß man sich den Stress mit nicht funktionierendem Selbstbauprogrammer nicht antun. Für Arduino und Bascom gibt es reichlich Hilfe und Tuts für Einsteiger. Die entsprechenden Foren sind auch nicht so arrogant wie hier. Viel Glück! Gruß, Norbert
Thomas E. schrieb: > Lothar schrieb: >> Hatte keine Ahnung was der AVR TFT Treiber genau macht und habe mich >> selbst gewundert, dass der fast ohne Änderungen auf einem LPC ARM lief. > > Der schlimmste Zustand einer Entwicklung ist, wenn es funktioniert, aber > der Entwickler selbst nicht weiß, warum es funktioniert... ;) Am interessantesten finde ich es immer, wenn nach Jahren der Code auf einmal nicht mehr funktioniert. Man schaut ihn sich an und stellt fest, dass das eigentlich nie hätte funktionieren dürfen.
Norbert S. schrieb
> sehr langer text....
Endlich mal eine Antw, die mir doch etwas weiterhilft.
no Debugger schrieb: > Naja Debugger hat's seit 30 Jahren bei mir nie gebraucht. > > Es geht auch ohne, Aber mit geht es doch viel einfacher und schneller...
Ebenfalls Norbert S. : > Es kommt aber auch sehr darauf an, was man vorhat Am Anfang die Basics, danach Timer, funk relaiskrte, selbstgebaute Lötstation etc. > und nicht zuletzt wie alt man ist. 17.
Prügelvereinsvorsitzender (hui den Namen musste ich kopieren ;D)
schrieb:
> der arme nOOb, jetzt hat er den Durchblick..
Ohh ja, das tue ich....
Um das Thema nochmal kurz anzusprechen: Ich denke ich kaufe mir einfach ein Buch, nur welches? Kann mir jemand was Empfehlen. Sollte nicht mehr als 20€ kosten, kann auch gebraucht sein etc.
Zum Beispiel: http://www.ebay-kleinanzeigen.de/s-anzeige/c++-das-grundlagen-buch/416546047-77-9549 oder für die "ultranichtswisser": http://www.ebay-kleinanzeigen.de/s-anzeige/programmier-buch-c++-fuer-kinder-mit-cd/410460556-76-805
Auf jeden Fall werde ich mir mal das durchlesen: https://download.heise.de/software/2fcdfa69f3829facad7f8b36f40cea42/56a8609b/102095/cplusplus.pdf
Kostet gar nichts: http://stefanfrings.de/mikrocontroller_buch/index.html Dieses Buch vermittelt kein großartig fundiertes Wissen. Aber es ermöglicht einen Einstieg. Danach wirst du gezielt die Literatur finden, die du brauchst.
@Stefan Us naja da werden mehr die basics der Elektronichen bauteile, löten etc. beschrieben, aber wie du schreibst, für den Einstieg... Ich lese mir mal mein verlinktes Teil durch, da gehts direkt los mit dem Programmieren.
Zum Reinspielen einfach mal bei halvar.at schauen, da steht ein sehr gut gemachtes Bascom-Tutorial. Ja, es ist Bascom und ja, Bascom hat nicht den besten Ruf. Zum Einsteigen gibt es aber nichts besseres - einfach zu lernen und benutzt Ablaufstrukturen, die du auch anderswo finden wirst - Schleife, Interrupt und Timer ist jetzt nichts was es nur bei Bascom gäbe. Mit Bascom und einem einfachen ATmega 8 kann man sich schon eine ganze Weile beschäftigen.
Putin schrieb: > Zum Reinspielen einfach mal bei halvar.at schauen, da steht ein > sehr gut > gemachtes Bascom-Tutorial. > > Ja, es ist Bascom und ja, Bascom hat nicht den besten Ruf. Zum > Einsteigen gibt es aber nichts besseres - einfach zu lernen und benutzt > Ablaufstrukturen, die du auch anderswo finden wirst - Schleife, > Interrupt und Timer ist jetzt nichts was es nur bei Bascom gäbe. Mit > Bascom und einem einfachen ATmega 8 kann man sich schon eine ganze Weile > beschäftigen. Alles richtig, alles gut und schön. Es gibt nur einen kleinen Schönheitsfehler beim Einsteigen in BASCOM und das ist, man muss es (für privat) erst mal kaufen, sprich 89 Tacken abdrücken. Diese Hürde gibt es bei LunaAVR nicht.
ach ja doch schrieb: > Es gibt nur einen kleinen > chönheitsfehler beim Einsteigen in BASCOM und das ist, man muss es (für > privat) erst mal kaufen, sprich 89 Tacken abdrücken. Diese Hürde gibt es > bei LunaAVR nicht. Dann nehme ich halt in Zukunft die Arduino software oder den Arduino selber als ftdi.
ach ja doch schrieb: > s gibt nur einen kleinen > Schönheitsfehler beim Einsteigen in BASCOM und das ist, man muss es (für > privat) erst mal kaufen, sprich 89 Tacken abdrücken. Das ist nicht wahr. Eine Testversion, die nur in der Codegröße auf 4KB begrenzt ist, kann man bei MCS (Hersteller) herunterladen. http://www.mcselec.com/index.php?option=com_docman&task=cat_view&gid=99&Itemid=54 4KB muß man erst mal "füllen" -besonders als Anfänger. mfG Paul
Paul B. schrieb: > ach ja doch schrieb: >> s gibt nur einen kleinen >> Schönheitsfehler beim Einsteigen in BASCOM und das ist, man muss es (für >> privat) erst mal kaufen, sprich 89 Tacken abdrücken. > > Das ist nicht wahr. Eine Testversion, die nur in der Codegröße auf 4KB > begrenzt ist, kann man bei MCS (Hersteller) herunterladen. > http://www.mcselec.com/index.php?option=com_docman... > > 4KB muß man erst mal "füllen" -besonders als Anfänger. > > mfG Paul Danke dir für den Hinweis. Irgendwie ist das auf deren Seite alles etwas unübersichtlich. Auch fehlen mir Versionshinweise. Die Dl-Version ist wohl bereits 4 Jahre alt. Mit den 4k gebe ich dir recht. Ich will auch beim Preis nicht grundsätzlich meckern. So eine Einmalzahlung ist mir persönlich sogar lieber als das Modell Jahreslizenzen. Das myAVR Workpad PLUS finde ich übrigens als Einstieg auch ganz interessant http://shop.myavr.de/index.php?sp=download.sp.php&suchwort=dl62
Flamewars mal wieder m( Es wurden ja einige vernünftige Varianten genannt. Es gibt z.B. noch die http://www.mikrocontroller.net/articles/Infineon_XMC Einfach an USB und IDE frei herunterladen und man kann auch debuggen. Und zum drölfzten male Assembler ist heutzutage nur bei bestimmten Gegebenheiten notwendig/sinnvoll. Jede Hochsprache wird vom Compiler idR in "besseren" Assembler übersetzt als man das per Hand machen kann. Beim Arduino hat man auch gleich noch eine Bibliothek dabei so das man sehr schnell zu funtionierendem Timer&Co. kommen kann ohne Bitgefrickel zu müssen.
kopf->tisch schrieb: > Beim Arduino hat man auch gleich noch eine Bibliothek dabei so das man > sehr schnell zu funtionierendem Timer&Co. kommen kann ohne Bitgefrickel > zu müssen. Das hat man bei Bascom auch. Trotzdem ist es mir lieber, Timer von "Hand" einzurichten -da weiß man, was man hat. Solche fertigen Sachen sind ganz nützlich, z.B. bei der Ausgabe auf LCD oder über die serielle Schnittstelle. Trotzdem habe ich dabei manchmal das Gefühl, durch eine Milchglasscheibe auf das Geschehen zu gucken. MfG Paul
Paul B. schrieb: > kopf->tisch schrieb: >> Beim Arduino hat man auch gleich noch eine Bibliothek dabei so das man >> sehr schnell zu funtionierendem Timer&Co. kommen kann ohne Bitgefrickel >> zu müssen. > > Das hat man bei Bascom auch. Trotzdem ist es mir lieber, Timer von > "Hand" einzurichten -da weiß man, was man hat. > Solche fertigen Sachen sind ganz nützlich, z.B. bei der Ausgabe auf LCD > oder über die serielle Schnittstelle. Trotzdem habe ich dabei manchmal > das Gefühl, durch eine Milchglasscheibe auf das Geschehen zu gucken. > > MfG Paul Es geht hier ja nicht darum das man das Datenblatt auswendig kennt und sämtliche Register per Bitmasken am besten in HEX reinhackt. Eine Bibliothek ist ja genau dafür da das Du Dir keine Gedanken machen mußt es aber geht ;-) Wieviele hier nutzen z.B. PeDas Entprellung und wieviele haben verstanden wie das funktionert ? Läuft trotzdem 1A ;-)
> Wieviele hier nutzen z.B. PeDas Entprellung und wieviele > haben verstanden wie das funktionert ? Ich habe verstanden, wie sie funktioniert und nutze sie trotzdem nicht. Das soll aber bitte nicht als Abwertung aufgefasst werden. Man kann aus dem Code einiges Lernen.
Claymore schrieb: > Stefan U. schrieb: >> Benutze stattdessen für den Anfang einen Texteditor und den avr-gcc >> Compiler. Mit komplexeren Entwicklungsumgebungen beschäftigt man sich >> später, wenn man die Grundlagen verstanden hat. > > Das kann ich so nicht unterschreiben. Besser gleich mit vernünftigen > Werkzeugen arbeiten, und dazu gehört ein richtiger Debugger. Sonst > besteht die Gefahr, dass man sich eine sehr umständliche Arbeitsweise > bei der Fehlersuche angewöhnt. Auch ich würde für den Anfang erst einmal zu einem ordentlichen Editor und dem avr-gcc raten. Bevor man einen Debugger sinnvoll einsetzen kann, muß man erst einmal die Grundlagen beherrschen. Außerdem braucht man auch keine IDE, um einen Debugger zu benutzen: avr-gdb existiert. Der Vorteil einer klassischen CLI-Toolchain ist, daß man versteht, was im Hintergrund passiert. Das ist wertvolles Wissen auch dann, wenn man sich später für eine IDE entscheidet. Außerdem läuft die klassische Toolchain nahezu überall und für beinahe jedes Target gleich. Gleichgültig, ob ich für Linux auf x86_64, auf ARM oder für AVR code: GNU Make, GCC-Compiler, GDB und die anderen Tools funktionieren immer nahezu gleich, was ich einmal gelernt habe kann ich überall nutzen.
Die DIskussion könnte fast 1:10 auch für Java gelten. Ich bin Leuten begegnet, die entwickeln seit Jahren mit Maven, sind aber nicht imstande, ein simples Hello-World Programm (bestehend aus einer einzigen *.java Datei) zu starten. Da frage ich mich dann schon, ob sich die Methodik in die richtige oder falsche Richtung entwickelt. Spätestens, wenn ein irrer Herrscher alle Computer durch einen EMP zerstört, müssen wir uns auf die Grundlagen besinnen und von neuem anfangen können. Zumindest fühle ich mich wohler, wenn ich zumindest theoretisch weiss, wie man eine Glühlampe baut und nutzt, ohne dafür eine App herunter laden zu müssen.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.