Hallo zusammen, ich bin absoluter Neueinsteiger in die Welt der Elektronik und Mikrocontroller Programmierung. Ein bisschen Programmierung habe ich in C, C+, Basic und VBA das ist aber auch schon alles ziemlich lange her. Auf meine alten Tage möchte ich mir nun nochmal ein neues Hobby zulegen und nachdem mich die Möglichkeiten der Mikrocontroller schon immer fasziniert haben würde ich es gerne damit versuchen. Konkretes Projekt gibt es noch keines, wenn mal ein bisschen Wissen da ist würde ich dies gerne in meinem großen Hobby Autoschrauben einsetzen. Ideen wären da ein A/F-Display, digitale Zusatzinstrumente mit Aufzeichnung (ich weiß, dass man das alles fertig kaufen kann und das wahrscheinlich auch noch billiger ist) und ähnliche Geschichten. Also ging es los mal ein paar Basisinfos einsammeln. Ehrlich gesagt bin ich inzwischen ratloser als am Anfang. Nun erhoffe ich mir eure Hilfe. Ich suche einen Einstieg in die Mikrokontrollerwelt. Gerne auch eine Art Start-Kit. Auf jeden Fall was, wo man auch solche Sachen lernt, die über die reine Programmierung hinausgehen wie z.B. Signalanpassung (also wie kriege ich das Signal eines von mir aus Sensors überhaupt erstmal in den Mikrokontroller rein), Ansteuerung von Ausgabegeräten wie LCD, TFT oder ähnlichem. Mir ist klar, dass es voraussichtlich nicht die einzig wahre Lösung gibt. Aber derzeit bin ich ziemlich überfordert und würde mich sehr über eure Anregungen freuen. Ciao, Stefan
Folge den Tutorials in diesem Forum, oder in Google oder kaufe ein Buch. Ganz besonders einfach ist der Einstieg warscheinlich mit einem Arduino oder einem mbed Controller. Wehr sich eher mit den Grundlagen beschäftigen will (ohne fertige Libraries zu nutzen), dem würde ich ein bliebiges AVR Mikrocontroller-Modul mit USB-UART empfehlen (z.B. von chip45 oder ebay) oder ein STM32 Discovery Board. Überlege Dir erstmal, ob Du mit einfachen 8 Bit anfangen möchtest, oder gleich mit 32bit loslegen willst. Ich pedänlich hatte noch keinen Bedarf, auf 32bit aufzurüsten. Aber wenn ich huete anfangen würde, würde ich warscheinlich gleich bei 32bit anfangen, da diese Controller nicht mehr wesentlich teurer sind, als 8bitter.
Ich sollte vielleicht noch dazu sagen, dass der Unterschied zwischen 8bit und 32bit Controller nicht nur die Busbreite ist, sondern die 32bit Controller haben in der Regel erheblich mehr I/O Features und sind deswegen schwieriger zu handhaben. Dennoch würde ich nicht von ihnen abraten, so schwierig sind sie auch nun wieder nicht.
Hallo, ich habe mit dem MSP-430-USB-Stick von TI angefangen. Es ist ein 16 Bit Controller der F201x - Reihe, die bis zu 2KB für Programme in C/C++ oder Assembler bereitstellen. http://www.ti.com/lsds/ti/microcontroller/overview.page Als IDE hatte ich anfangs die "IAR Embedded Workbench", hinterher die "Code Composer Studio™ IDE", welche auf Eclipse basiert. Beide sind kostenlos. Neu ist "Open Source MSPGCC", im Beta Stadium. Tools & Software for MSP430 Ultra-Low Power 16-bit MCUs http://www.ti.com/lsds/ti/microcontroller/16-bit_msp430/tools_software.page Es gibt reichlich Unterstützung, allerdings ist der der englisch kann von Vorteil. Ist sogar billiger als bei Reichelt: http://www.conrad.de/ce/de/product/170285/MSP-430-USB-Stick-Entwicklungstool-Texas-Instruments-eZ430-F2013/?ref=062 Ist neuer als der Stick, Controller kein SMD. http://www.conrad.de/ce/de/product/414784/MSP-EXP430G2-LaunchPad-Texas-Instruments-fuer-MSP430G2xx-Microcontroller/?ref=062 Wenn es etwas gehobener sein soll, dann wäre dies etwas: http://www.espruino.com/ RASPBERRY-PI ist heutzutage sehr angesagt. http://www.reichelt.de/Programmer-Entwicklungstools/RASPBERRY-PI-B/3/index.html?&ACTION=3&LA=2&ARTICLE=133474&GROUPID=2969&artnr=RASPBERRY+PI+B Oder ARDUINO: http://www.reichelt.de/Programmer-Entwicklungstools/ARDUINO-MEGA/3/index.html?&ACTION=3&LA=2&ARTICLE=119696&GROUPID=2969&artnr=ARDUINO+MEGA Gruss Klaus.
:
Bearbeitet durch User
Stefan Tully schrieb: > Auf meine alten Tage möchte ich mir nun nochmal ein neues Hobby zulegen Hallo Stefan, was heisst hier alte Tage? Ich bin 64 und habe mit den Mikrocontrollern vor 2 Jahren angefangen. Gestartet bin ich mit einem Netzteil, Breadboard, ATMega168 und Bascom. Und einen gescheiten Programmer brauchst Du noch. Nimm gleich den AVRISP MK2 für ca. 40 Euro von Atmel, damit ersparst Du Dir dann viel Ärger. Den Einstieg habe ich in wenigen Tagen geschaft, da liefen schon eigene Programme. Heute mach ich mehr mit Luna, zu C habe ich nicht so wirklich den Draht. Den braucht man sich auch nicht einreden lassen, denn bei uns ist es halt nur noch Hobby. Da geht es auch super ohne C. Lass Dir hier auch keine 32 Bit'er wie STM usw. einreden. Damit ist der Hobby-Einsteiger erst mal überfordert und es kann leicht zur Frustration werden. Übrigens ist ein Oszi oder Logik-Analyzer ganz hilfreich. Wenn Dir ein Oszi zu teuer ist, nimm einen billigen Logik-Analyzer.
:
Bearbeitet durch User
Albert M. schrieb: > zu C habe ich nicht so wirklich > den Draht. Den braucht man sich auch nicht einreden lassen, denn bei uns > ist es halt nur noch Hobby. Da geht es auch super ohne C. Ja alles Teufelswerk. Also die Rangliste ist einfach zu merken: C - Industriestandard. Nutzen die wirklich coolen Jungs die was drauf haben (z.B. ich) Bascom - für Verlierer Arduino - für Leute die sogar für Bascom zu doof sind (weil da keine HW fix und fertig dabei ist). Pascal - Für Leute wo es evt. zu Bascom reichen würde, aber die kennen nix anderes weil sie früher mal (anno dunnemals) schon mit Pascal programmiert haben und es ihnen überhaupt nichts ausmacht dass die Sprache 1. doof und 2. tot ist. Da ist alles verloren. Nicht schön. Einfach weitergehen. LunaAVR - Lu was?
:
Bearbeitet durch User
kopfkratz Also gehe mal genau anders herum vor: 1. Was willst Du bauen ? 2. Welche Informationen müssen dafür verarbeitet werden ? 3. Welches ist der geringste Aufwand das zu realisieren ? Wenn Du dagegen nur einfach LEDs zappeln lassen willst oder Deinen Anverwandten den Fernseher sporadisch ausschalten oder nerviges gepiepse in Nachbars Garten veranstalten, dann nimm halt den günstigsten µC der PWM kann ;-) AVR Einstieg gibt's um 10,-, entweder als Arduino oder 5,- USBASPclone und Steckbrett und ATMega88A oder Tiny mit Hühnerfutter = Widerstände, LEDs, Kondensatoren usw. usf. PICKit ist auch nicht esentlich teurer. Und die aktuellen Arduinos gibt's noch in AVR32, STM32 (ARM) und dann gab es auch noch irgenwo ein MIPS-Board auch 32bittig. Der Vorteil von Arduino ist das Rapidprototyping da schon alle Bibliotheken vorhanden sind, hat den Nachteil das er Overhead produziert und den Vorteil das die Sketches i.d.R. leicht auf andere Arduinos anpaßbar sind. Es gibt auch einige Bücher mit Starterkits wo man in µC eingeführt wird. Allerdings gibt's da auch viele die an die Tutorials hier nicht herankommen m( Also entscheide Dich ob Du nun ein konkretes Projekt hast, z.B. wann wecke ich Oma wenn sie so laut schnarcht das ich meine "Lieblingswerbung" nicht mehr verstehen kann oder ob Du einfach mal ausprobieren willst wie Du einen Poti auswertest um damit via PWM eine LED zu dimmen. Rechne mal mit 50-100 Euro um was zu haben mit dem Du arbeiten kannst, Multimeter braucht es auf jeden Fall Oszi macht Sinn muß aber anfangs nicht vor allem bei digitaler Bastelei.
@cyblord Wieder mal so ein dümmlicher Kommentar, aber von Dir kennt man es ja nicht anders. Und wer lesen kann ist im Vorteil. Es geht ums Hobby im Alter. Warum in aller Welt sollte man sich da unbedingt das nervtötende C antun? Und cool waren wir bereits, als Du noch nicht mal ein Gedanke warst.
:
Bearbeitet durch User
Albert M. schrieb: > @cyblord > > Wieder mal so ein dümmlicher Kommentar, aber von Dir kennt man es ja > nicht anders. Das schneidet tief. Und sowas kurz vor Weihnachten... Außerdem war das ja nur eine stark verkürzte Zusammenfassung des Fazits. Ich kann ja die lange Fassung nachliefern aber ich fürchte das will keiner. > cool waren wir bereits, als Du noch nicht mal ein Gedanke warst. Ohne C? Wie soll das gehen? Man ist nie zu alt um es richtig zu machen.
:)
Stefan Tully schrieb: > Auf meine alten Tage möchte ich mir nun nochmal ein neues Hobby zulegen > und nachdem mich die Möglichkeiten der Mikrocontroller schon immer > fasziniert haben würde ich es gerne damit versuchen. Na dann herzlich willkommen :-D stefan us schrieb: > Ganz besonders einfach ist der Einstieg warscheinlich mit einem Arduino > oder einem mbed Controller. Arduino würde ich auch am Anfang empfehlen. Übersichtliche 8-Bit CPU für die man extreme preiswert kleine Boards & Peripherie kriegt. Kommt man (relative) schnell mit klar. Das Arduino Projekt benutzt eine "entschärfte" C++ Variante. Also auch für Anfänger/Wiedereinsteiger geeignet. Wenn Du dann tiefer einsteigen willst, kannst du relative einfach die Hardware auch mit anderen Tools benutzen (dann ggf. mit einem Programmer, der etwas €30 kosten). Auf komplexere uC's kannst Du dann immer noch umsteigen. Am Anfang kann das aber schnell entnervend schwierig werden. Grüße & viel Spass Andreas P.S: cyblord ---- schrieb: > Ohne C? Wie soll das gehen? Man ist nie zu alt um es richtig zu machen. Wir drücken Dir alle die Daumen (obwohl die Hoffnung langsam schwindet ...)^^
Wenn du mit LCD und TFT später rumspielen willst wirst du dir mit einem 8 bitter da keine Freude machen. Ja ich weiß es geht aber die Ressourcen sind da so knapp das es keinen Spass macht. Ja und es gibt Leute die genau daran Spass haben..... Nimm die ein fertiges Entwicklungskit auf den 32 Bit Arm. wie zb : http://www.ti.com/ww/en/launchpad/launchpads-tivac.html#tabs oder auch die von STM. Hier gibt es auch umfangreiche Libs von den Herstellern die einiges Vereinfachen. Für dne Anfang recht gut um zügig zu einem Erfolgserlebnis zu kommen. Später kann man ja immer noch diese Libs durch eigene Code ersetzen, wenn man denn etwas effizienteres hinbekommt. Da ist dann auch die komplette Toolkette für die Entwicklung, also Compiler, Debugger direkt mit dabei und es funktioniert. Es macht wirklich kein Spass wenn man am Anfang nicht mal weiß wo der Fehler liegt. Das eigene Programm, das Board, die Compilersettings, der Debugger,....... Wenn du damit ins Auto willst hast du dir das schlimmste Umfeld ausgesucht das du haben kannst. * Versaute Versorgungspannung. * Viele Störungen * hohe mechanische und thermische Belastung,...
Ralph schrieb: > Wenn du damit ins Auto willst hast du dir das schlimmste Umfeld > ausgesucht das du haben kannst. > * Versaute Versorgungspannung. > * Viele Störungen > * hohe mechanische und thermische Belastung,... Das dachte ich mir auch. Da soll er gleich nochmal ein paar Monate E-Technikgrundlagen mit einplanen damit er entsprechende Entstörschaltungen halbwegs versteht oder zumindest die ganze Problematik überblickt. Was macht eigentlich der Krankenpfleger mit seinem Bordcomputer für seinen Reiskocher?
Hier hat jemand ein ähnliche Frage, kannst du dir mal durchlesen: Beitrag "Einstieg unter Mac OS X: AVR, Arduino, oder PIC18/24?"
Ralph schrieb: > Nimm die ein fertiges Entwicklungskit auf den 32 Bit Arm. > > wie zb : > http://www.ti.com/ww/en/launchpad/launchpads-tivac.html#tabs Das Teil sieht wirklich gut aus. Aber ist der nicht ein bisschen zu kompliziert für den Anfang ? Grüße Andreas
Warum erscheint eigentlich diese scheiß Frage alle drei Wochen hier in diesem Forum? Können die Leute die Suchfunktion bzw. - Maschinen nicht bedienen? Das hat ja fast den Level von "Welches Oszilloskop soll ich kaufen?" in KFZ-Foren wäre das "Welches Öl soll ich nehmen?"
Mit viel Geld. Ich mache das jetzt ca. zwei Jahre und alles in allem, also Bauteile, Messgeräte, Arbeitsplatzausbau, Hilfsmittel usw., habe ich bis jetzt ca. 5000 Euro ausgegeben.
Stefan Tully schrieb: > Also ging es los mal ein paar Basisinfos einsammeln. Ehrlich gesagt bin > ich inzwischen ratloser als am Anfang. Nun erhoffe ich mir eure Hilfe. Kein Wunder, ist mir vor kurzem auch so gegangen :o) Ich habe mir für den Start das Pollin-Board als Fertigmodul (Pollin 810 074 für 23 EUR), serielle Kabel und ein paar Atmega8 und Atmega32 in DIP-Ausführung gekauft. Dazu noch einen usbasp-Programmer für unter 10 EUR. Dann noch ein Steckbrett (oder auch ein paar mehr), Drahtbrücken, Steckverbinder, Kroko-Verbinder und div. Standardbauteil-Sortimente von Vellemann und andere Standard-Bauteile. Ein einfaches Labornetzgerät, ein paar Billig-Multimeter und eine einfache Lötstation für den Anfang. Zum Programmieren habe ich mir C, BASCOM und LunaAVR angesehen und bin dann bei Luna geblieben. Ada habe ich auch kurz ausprobiert, aber ich denke das kann man als Hobbiest/Einsteiger vergessen. Schau einfach, was Dir am Anfang besser liegt, umsteigen kann man ja jederzeit. Damit sollte man schon mal alles haben um eine LED leuchten zu lassen. > Ich suche einen Einstieg in die Mikrokontrollerwelt. Gerne auch eine Art > Start-Kit. Auf jeden Fall was, wo man auch solche Sachen lernt, die über > die reine Programmierung hinausgehen wie z.B. Signalanpassung (also wie > kriege ich das Signal eines von mir aus Sensors überhaupt erstmal in den > Mikrokontroller rein), Ansteuerung von Ausgabegeräten wie LCD, TFT oder > ähnlichem. Da haben wir doch schon Deine ersten "Projekte" :o) Also noch ein paar LCDs (z.B. Pollin 120 421) geordert und ein I2C-Modul (z.B. Pollin 810 145). Als analoge Sensoren vielleicht erstmal Photo-, NTC- und PTC-Widerstände. Wie das umgesetzt wird steht hier in die zahlreichen Wiki-Artikel. Da ist z.B. auch http://www.sprut.de/electronic/temeratur/temp.htm verlinkt. Ich denke wenn Du dann an diesem Punkt bist, hast Du schon einen gewissen Überblick über das Thema gewonnen. Das soll Dich jetzt natürlich nicht vom Fragen abhalten. Es gibt da sicherlich noch viel Anzumerken und zu Diskutieren, aber übersichtlicher wird es dadurch für Dich nicht. Du kannst mir auch gerne eine PN schicken, wenn Du Dir bei Kleinigkeiten unsicher bist und Dir hier im Forum keine Blöße geben willst. Manchmal herrscht hier halt ein etwas rustikaler Ton. Auf jeden Fall wünsche ich Dir viel Spaß und Erfolg! Klaus P.S.: Falls Du wegen der Grundausstattung detailierte Vorschläge brauchen kannst, bitte eine kurze PN. Ich habe da einiges in Excel abgespeichert.
Andreas H. schrieb: > Aber ist der nicht ein bisschen zu kompliziert für den Anfang ? Wenn du die mitgelieferten Libs benutzt dann nicht. Die nehmen viel Detailarbeit ab. Später kann man ja immer noch mit den Details spielen, falls es nötig ist.
Ralph schrieb: > Andreas H. schrieb: >> Aber ist der nicht ein bisschen zu kompliziert für den Anfang ? > > Wenn du die mitgelieferten Libs benutzt dann nicht. > > Die nehmen viel Detailarbeit ab. Sind da die Quellen verfügbar ? Oder sitzt da ein Anfänger plötzlich auf einem Problem, wo er anfangen muss eine M4 auf bare Metal zu debuggen ? Ich mag ja die Cortexe ganz gern. Aber ich würde es keinem Anfänger zumuten wollen damit einzusteigen. Grüße Andreas
Foldi schrabte:
>Mit viel Geld.
Das kann ich nicht bestätigen. Ein teurer und umfangreicher
Meßgerätepark
ist auch noch keine Garantie dafür, logische Fehler in Programmen zu
erkennen.
Viele Bauelemente kann man auch bei "Schlachtfesten" von alten Geräten
gewinnen -der Siebensegmentanzeige z.B. ist es völlig Brust, ob sie
schon
20 Jahre lang Kanalanzeige in einem analogen Sat-Receiver war. Da finden
sich auch kleine Tasterchen und Festspannungsregler, Transistörchen
u.s.w.
Das Problem wird sich in den kommenden Jahren noch verschärfen:
Viele Rentner, die mit Gewalt in die vorzeitige Rente gezwungen wurden.
Die haben ganz geringe Renten und wollen trotzdem ihr Hobby betreiben.
:-(
MfG Paul
Andreas H. schrieb: > Sind da die Quellen verfügbar ? Oder sitzt da ein Anfänger plötzlich auf > einem Problem, wo er anfangen muss eine M4 auf bare Metal zu debuggen ? Beim TI Ja. Da gibt es beim Softwarepacket die ganzen Libs als C -Code mit einem PDF als Beschreibung der Schnittstellen. Wie das beim STM aussieht weiß ich nicht.
cyblord ---- schrieb: > C - Industriestandard. Nutzen die wirklich coolen Jungs die was drauf > haben (z.B. ich) > > Bascom - für Verlierer > > Arduino - für Leute die sogar für Bascom zu doof sind (weil da keine HW > fix und fertig dabei ist). > > Pascal - Für Leute wo es evt. zu Bascom reichen würde, aber die kennen > nix anderes weil sie früher mal (anno dunnemals) schon mit Pascal > programmiert haben und es ihnen überhaupt nichts ausmacht dass die > Sprache 1. doof und 2. tot ist. Da ist alles verloren. Nicht schön. > Einfach weitergehen. So, so, du gehörst zu den coolen Jungs, die was drauf haben? Wenn man keine Ahnung hat, sollte man einfach mal die F... halten. Ich denke, du gehörst eher zu den dummen Jungs, die mit Scheuklappen durchs Leben gehen und in ihrer kleinen Welt gefangen sind. Die verpassen schnell den Zug und gehören morgen zum alten Eisen.
Bitte unterlasst diese Beleidigungen. Solche Angebereien, wie "ich hab was drauf, und die anderen sind doof" halte ich für unangebracht, ebenso die Reaktionen darauf. Wer wirklich gut ist, weiss das und hat es nicht nötig, darüber zu diskutieren. Wer hingegen andere Leute schlecht macht, outet sich als unangenehme Person, die gemieden wird. Stellt euch mal vor, Ihr sitzt im Bewerbungsgespräch für euren Traumjob, und dann zieht der künftige Chef Ausdrücke von solchen Diskussionsbeiträgen aus der Tasche. Und dann sagt er: Sowas wollen wir in unserer Firma aber nicht haben, ich wünsche Ihnen viel Erfolg bei der weiteren Suche nach einem Job. Denkt mal darüber nach. Zum Thema, also @Stefan Tully: Da du in jungen Jahren schon einige Programmiersprachen angewendet hast, gehe ich davon aus, dass du dich neu einarbeiten wirst. Das wird dir aber warschlich recht schnell gelingen, ganz egal in welcher Programmiersprache. Für den Einstieg ist es hilfreich, eine fertige Hardware vorliegen zu haben, bei der man weiss, dass sie funktioniert. Zum Beispiel ein AVR mit einer LED und einer Programmierschnittstelle mitsamt Programmieradapter (oder USB Bootloader). Das kann man ab 20 Euro haben. Wenn Du die erste LED blinkend hast, dann kannst Du anfangen, eigene Hardware zu entwicklen. Wenn man 10 neue Sache gleichzeitig einsetzt, hat man halt auch viele mögliche Fehlerstellen. Da ist dann die Chance auf einen Doppelfehler (oder gar mehr) hoch, und die können sehr frustrierend sein. Also: Nimm ein fertiges Modul. Raspberyy Pi würde ich jetzt nicht zu den Mikrocontrollern zählen, weil da ein ganzes Linux drauf läuft. Sie werden demnach auch ganz anders programmiert, als Mikrocontroller, nämlich eher wie PC's.
Stefan Tully schrieb: > meinem großen Hobby Autoschrauben Ach.. jemandem zu irgendeiner Variante zu raten, ist schwierig. Also am Autoschrauben bist du schon lange interessiert, ich setze also mal voraus, daß du in maschinenbaulichen Dingen demnach bewandert bist, die Reihe der Passungen auswendig kannst und mit Werkzeugmaschinen umgehen kannst. Ne Garage dafür hast du sicherlich auch. Richtig? Jetzt erstmal meine Fragen: Bist du Rentner und hast Zeit? Hast du auch sowas wie nen Elektronik-Basteltisch? Und die einschlägigen Werkzeuge dafür (geeigneter Lötkolben, Multimeter, kleines Labornetzteil, ne gute Lupe oder Binokular-Lupe zum Aufsetzen, feiner Seitenschneider, Werkzeug) Auf was für Bezugsquellen kannst du zugreifen? Sag jetzt nicht Conrad, das wäre nicht wirklich gut. Wie gut ist dein Englisch? Weißt du, Mikrocontroller sind KEIN Selbstzweck, sondern sie sollen in irgendeiner Schaltung einen sinnvollen Zweck erfüllen und diese Schaltung soll einem Gerät seine Funktion geben. Also ist das Ganze mit Beschaffung von Teilen verbunden, mit dem Erstellen von Schaltungen, mit dem kreieren von Leiterplatten und deren Anfertigung, mit dem Bestücken, InBetriebNehmen, Programmieren. Taste dich zu allererst der Reihe nach an all diese Disziplinen heran. Es muß auf den Anfang nicht das Programmieren eines besorgten Eval-Boards sein. Im Gegenteil, denn Eval-Boards sind Werbemittel, mit denen die Hersteller den Kunden ihre Teile schmackhaft machen wollen und die deshalb nie und nimmer für eine wirkliche Anwendung gedacht und geeignet sind. Immer nur geht's um's Ausprobieren von irgendwelchen Bestandteilen, aber nie um's echte Benutzen. Das Einzige, was gut ist an Eval-Boards ist, daß man sie gegebenenfalls auf einschlägigen Veranstaltungen kostenlos abgreifen kann. Beispiel: Im nächsten Frühjahr gibt's in Nürnberg wieder die "Embedded" Messe. Da kannst auch du hin, an kostenlose Eintrittskarten kommt man im Internet, wenn man einen sinnvollen Grund hat. Den braucht man zusammen mit einem Stapel Visitenkarten auch drinnen in der Messe. Ich rate dir, mal mit nem Lehrer vom Gymnasium deines Enkels zu reden, Inhalt so etwa "Arbeitsgemeinschaft Mikrorechentechnik" mal anzudenken. Pädagigik plus Visitenkarte reicht eigentlich. In der Zwischenzeit solltest du dich bei einigen µC Herstellern einlesen, konkret bei MicroChip, NXP und ST-Microelectronic. Zu Atmel kann ich dir nicht wirklich raten, dafür gibt es hier im Forum genug andere. Also lies erstmal kritisch zur Orientierung. Alle wollen glänzen und ihr Zeugs gut darstellen. Also hier noch nicht sich festlegen!!! "ich bin absoluter Neueinsteiger in die Welt der Elektronik" Das ist natürlich nicht die beste Startposition. Also lerne erstmal, Elektronik mit Strom zu versorgen. Klingt albern? Isses aber nicht. Sowohl für Netzbetrieb als auch für 12 Volt am Auto brauchst du Spannungsregler, Siebmittel, Schutzmittel, Gleichrichter usw. bis du auf den 5 Volt oder neuerdings 3.3 Volt bist, die für die meisten µC gebraucht werden. Auch sowas wie Aufladeschaltungen für Li-Akkus gehören dazu. Also lernen, für sowas gute und sichere Schaltungen zu machen und auf Leiterplatte zu bringen. Das ist der zweite Punkt: Schaltungen und Leiterplatten entwerfen. Probiere aus, was es dafür an benutzbaren Programmen gibt und ob du damit klar kommst. Erst nachdem du das in der Tasche hast, solltest du anfangen, dir nähere Gedanken über Mikrocontroller und deren Toolchaines zu machen. So. Bis hierhin hast du garantiert genug zu tun. Zum allerersten Reingucken kannst du dir nebenbei die "Lernbetty" hier in der Codesammlung runterladen. Das ist ne alternative Software für eine Fernbedienung namens "Betty", die es bei Pollin für billig Geld gibt. Das Nette daran ist, daß sie ein Grafik-Display hat und im Inneren einen ARM7 Controller, der schon einiges an Rechenleistung aufweist. Das Lernbetty-Basisprogramm stellt einiges an Funktionen als API zur Verfügung und so kann man damit Texte, Grafik und S/W-Bilder anzeigen, kurze Audio-Stücke spielen (auch Sprache) und man hat ein Megabyte für Anwendungsprogramme zur Verfügung. Lesen kostet nix, die Betty bei Pollin auch fast nix und die Quellen können als Anschauungsmaterial für Eigenes herhalten. Ach ja, Sozobon kann man auch drauf spielen. W.S.
Mit solchen Fragen "Mit was in die Mikrokontrollerwelt einsteigen?" darf ich mich jeden Tag im Auftrag von Halbleiterherstellern beschaeftigen. Die fragen sich genau dasselbe, nur aus einem anderen Blickwinkel. Wie machen wir es einem potentiellen zukuenftigen Kunden moeglichst einfach mit unserem microcontroller zu arbeiten? Im Rahmen dieser Fragen haben wir (ein Team von mehreren Ingenieuren mit Software Hintergrund) verschiedenste Kits und Hersteller angesehen. Hier ist die Minimalfassung des Ergenisses: Am schnellsten eine LED am blinken hatten wir mit mbed aber auch mit Arduino waren wir sehr schnell. In der Zeitmessung war Download und Installation der Software Pakete mitberechnet, deshalb konnten alle Programme, die erst mal 500 MB runterladen und dann 30 Minuten Installation verlangen nicht mithalten. Nach dem Blinken mit LEDs waren serielle Kommunikationsschnittstellen gefragt. Das ging immer noch hervorragend mit mbed und Arduino. Wenn also die microcontroller nicht das Ziel der Erkundung sondern das Mittel zum Zweck "Autoschrauben" sind, dann wuerde ich zu mbed/Arduino raten. Wenn allerdings ein freies Programmieren und spaeter Algorithmen auf dem Plan stehen, dann so frueh wie moeglich auf eine professionelle Umgebung umschalten. Kostenlos kommen als solche in Frage (ohne Wertung) LPCXpresso von NXP, Atmel Studio, CodeWarrior von Freescale, Atollic fuer verschiedene Chips und noch ein paar mehr. All die genannten Pakete gibt es auch als kostenpflichtige Versionen, dann fallen Einschraenkungen wie Codegroesse oder fehlende C++ Unterstuetzung weg. Atmel ist eine Ausnahme, das Studio hat auch in der kostenlosen Version keine Beschraenkungen. Tolle Hardware Kits, die den Start einfach machen: LPCXpresso http://www.embeddedartists.com Freedom Board von Freescale http://www.freescale.com/FRDM-KL25Z Atmel Xplained Pro http://www.atmel.com/products/microcontrollers/avr/xplainedpro.aspx Jetzt habe ich hoffentlich etwas mehr zur Klaerung als zur weiteren Verwirrung beigetragen. Robert
Eine schöne Zusammenfassung und vor allem der Hinweis zu den Einsteigerprogrammen. Auch der Hinweis auf die Beschränkungen ist hilfreich. Da ich noch vor nicht all zu langer Zeit selbst eingestiegen bin, kann ich das auch so bestätigen, allerdings kommen noch ein paar zusätzliche Hinweise von mir. Es sind nicht nur die unbeschränkte Software oder fertige Produkte die den Anfang leichter machen, auch die Beschaffung von günstigen Mikrocontrollern, die angebotenen Bauformen spielen, gerade für den Einsteiger, auch eine wesentliche Rolle. Auch den Umstieg ziemlich schnell zu vollziehen ist richtig, denn man will nicht immer so ein Arduino Board verbauen, obwohl das unterm Strich sogar mal günstiger sein kann und die kleinen Nanos bieten sich dafür an. Zu den Bezugsmöglichkeiten ein Beispiel: Gestern habe ich mich mal ein wenig nach Holtek umgesehen, weil diese Controller in immer mehr Geräten zu finden sind (vor allem Haushaltsgeräten). Bei den üblichen Verdächtigen, hier Conrad und Reichelt, sind diese µC's nicht zu beziehen. Aus diesem Grund fallen diese schon mal raus. Architektur hin oder her, krieg ich das Zeug erst gar nicht oder Wochen später, dann ist das alles ziemlich unwichtig. Genauso wenig wird man als Anfänger einen Chip im QF-Gehäuse, mit 100 Anschlüssen selbst in irgendeine Schaltung verbauen wollen. Der Reiz an SMD Bauteile kommt bei mir jetzt erst, nach zwei Jahren auf. Im Moment hat für mich bei allen Systemen Atmel noch die Nase weit vorn, auch wenn Dave L. Jones was anderes darüber denkt und die Vorteile von PIC gut erklärt. Das ganze Zeug ist ohnehin sau teuer, und hier meine ich am wenigsten die Mikrocontroller, sondern viel mehr alle Messwerkzeuge und die gesamte Ausstattung die man so braucht. Soll ich dann noch die Software kaufen, um die Controller eines Herstellers überhaupt verwenden zu können? Ich finde nein, denn wenn ich die nicht programmieren kann oder nur, wenn ich teure Software gekauft habe, dann sind diese µC für mich wertlos. Ich finde so was gehört kostenlos dazu. Man braucht ja nur mal sehen was man sonst noch so an Software braucht und was die so kostet (ich werfe mal Altium Designer in den Raum). Sicher, man könnte jetzt sagen, für den Niet brauchst du auch eine Nietzange und die musst du auch kaufen, aber bei Mikrocontrollern sehe ich das einfach anders.
:
Bearbeitet durch User
Stefan us schrieb: > Also: Nimm ein fertiges Modul. Ein Beispiel dafür wäre ein Arduino UNO mit steckbarem ATmega328. Dazu ein paar LEDs, ein, zwei Schalter/Taster und ein paar Widerstände mit 1k. Das Arduino-Board bietet neben der Programmierfunktion auch eine serielle Schnittstelle zum PC über ein USB-Kabel, worüber auch die Stromversorgung läuft. Natürlich kann man im Arduino-Dialekt programmieren, aber ebenso ein reines C-Programm schreiben, welches mit main() beginnt. Mit den genannten Bauteilen kann man Ausgaben auf Ausgänge (LED) und Eingaben per Taster/Schalter realisieren. Wenn das Ganze dann noch per Timerinterrupt und Entprellung per Software erfolgt, hat man die Gundfunktionen kennengelernt. Per RS232 Schnittstelle - über den vorhandenen USB-Umsetzer - kann man sich interne Zahlenwerte ausgeben und ganz konkret analoge Werte (Temperatur, Spannung...) über den ADC erfassen. Falls Du weiter am Ball bleiben möchtest, würde ich zum AVR-Studio 4.19 raten (die aktuelle 6.1 Version ist viel zu überladen) und zum AVRISP MK2, wie er oben schon genannte wurde. (Das AVR-Studio ist kostenlos und kann auch ohne vorhandene Hardware den Programmablauf simulieren). Alle Vorschläge, die zum ARM als Einstiegsprozessor raten, solltest Du völlig ignorieren. Wenn Du ein paar Balkonpflanzen (Petersilie, Schnittlauch) ernten möchtest, nimmst Du eine kleine handliche Schere und keine 2-Takter Heckenschere, die 100m Buchenhecke bis 20mm Astdurchmesser pro Tag schafft.
m.n. schrieb: > und zum AVRISP > MK2 Ohne vernünftigen Debugger würde ich einen µC nicht mal mit der Kneifzange anfassen. Der Lerneffekt durch das Visualisieren der Prozessorregister ist enorm. Außerdem ist es wahnsinnig komfortabel. Ohne Debugger zu arbeiten ist eine Methode aus der Steinzeit. m.n. schrieb: > Alle Vorschläge, die zum ARM als Einstiegsprozessor raten, solltest Du > völlig ignorieren. Alle Ratschläge ohne vernünftige Begründung solltest du völlig ignorieren.
Antimedial schrieb: > Alle Ratschläge ohne vernünftige Begründung solltest du völlig > ignorieren. Das mache ich dann hiermit.
Das mit dem Ignorieren hast du wohl noch nicht wirklich verstanden.
m.n. schrieb: > Natürlich kann man im Arduino-Dialekt programmieren Das liest man hier ständig. Bitte erkläre es doch einmal für Doofe: Was ist ein Arduino Dialekt?
Ich will auch ... >Das liest man hier ständig. Bitte erkläre es doch einmal für Doofe: Was >ist ein Arduino Dialekt? Ein Arduino Dialekt ist, wenn ein digitalWrite(pin, HIGH); digitalWrite(pin, LOW); 5us dauert, weil es durch zweiunddrölfzig Hardware abstraction layer gelaufen ist und doch nur das gleiche tut wie ein: GPIOC->ODR |= 0x40; GPIOC->ODR &= ~0x40; das ein paar ns dauert. Ein wenig Zuckerguss der verschleiert womit man es eigentlich zu tun hat. Tausche Performance gegen Übersichtlichkeit ist die Devise. Ist doch lattenpappenegal womit man anfängt. Man nehme irgendeine MCU Familie und irgendeine Sprache und fange an. Lernen muss ich das eine und das andere, das tut sich alles nicht viel. Ab 5€ ist man für ein tuti kompletti Eval Board + Programmer + Debugger + IDE dabei. (STM8S Value Line Discovery + IAR C-Compiler 8k free edition) Ob PIC, AVR, ARM oder LMAA ist doch im Endeffekt alles der gleiche Sch... Mit der Zeit wird man dann schon herausfinden wo es persönlich hakt und welche Sprache einem liegt. Bascom oder Arduino sind doch für den Anfang garnicht schlecht, nehmen viel ab, stehen aber nur auf einer handverlesenen Auswahl von MCUs zur Verfügung. Wenn es dann später ein wenig performanter sein darf dann ist der Schritt zu Assembler oder C nicht mehr so schlimm. @cyblord Ja, die geilen wissen an C auch zu schätzen das es extrem easy zu erlernen ist und auf wirklich jedem noch so absurdem MCU Sonderling zur Verfügung steht. Und NEIN, Sarkasmus funzt hier im Forum nicht wirklich.
Stefan schrieb: > Das liest man hier ständig. Bitte erkläre es doch einmal für Doofe: Was > ist ein Arduino Dialekt? Wie schon von mknoelke geschrieben und dann noch die Eigenart, als Grundfunktionen setup() und loop() aufzurufen. Selber habe ich das noch nie genutzt, weil ich immer Quellcode vom AVR Studio in den Editor kopiert habe. Der Editor ist - glaube ich - extrem beschränkt, wie man mehrere Quelldateien zufammenfaßt weiß ich nicht und, welche Peripherie von den diversen Bibliotheken beschlagnahmt wird, ist völlig intransparent. Aber das kleine Bißchen Hardware ist für den Anfang lötfrei zu verwenden und die USB-Anbindung an einen PC ist sehr einfach. Ich sehe den TO als einen Anfänger, der ohne klares Ziel noch nicht 'verbissen' genug ist, um für die Lösung seines Problems eine hohe Leidensbereitschaft mitzubringen. Daher braucht er als Allererstes ein Erfolgserlebnis, das ihn irgendwann auf seine eigene 'Spur' bringt. Das schafft man am besten mit schlichter Soft- und Hardware, die überschaubar dokumentiert ist. Ein Arduino-Board macht es sehr einfach ein weihnachtliches "Hallo Geld" auf dem PC anzuzeigen.
Hallo zusammen, herzlichen Dank für die Vielzahl an umfassenden Antworten. Ihr habt mir schon jetzt sehr weitergeholfen. Für mich inzwischen klar: Ich muss den Elektronik Einsteig gleich mitmachen. Dazu braucht es die entsprechende Grundausstattung. Ich habe mal ein Excel angehangen, was ich mir besorgen würde. Bei den Bauteilen selbst habe ich mich nach dem "Absolute Beginners" Artikel hier gerichtet, bei den Stückzahlen habe ich, wie jedem erfahrenen sicherlich sofort auffällt, einfach mal ins Blaue geraten. Es würde mich sehr freuen, wenn sich jemand die Mühe machen würde und mal einen Blick auf die Liste wirft und korrigierend eingreift wo notwendig. An Werkzeug möchte ich erstmal nichts zukaufen. Ich habe schon lange ein Metex 3640 (Multimeter) bis jetzt hat das für mich immer gereicht, ich hoffe, das tut es für dein Einstieg in die Elektronikwelt auch. Ansonsten ist meine Ausstattung an Handwerkzeugen recht umfangreich und alles was im Tutorial angeführt ist, ist vorhanden. Sollte die Ausführung für den neuen Anwendungszweck nicht taugen, würde ich einzeln nachkaufen. Lötkolben habe ich aktuell so ein Teil: http://www.ersa.de/art-0340kd-257-1059.html Für Kabelschuhe anlöten oder mal ein Kabel flicken hat das bisher gereicht, für Eletronikbauteile ist das Teil wohl weniger geeignet. Sobald es vom Steckbrett zu "richtigen" Platinen geht muss ich mir dann wohl eine Lötstation leisten. Oszilloskop wäre theoretisch ein Hameg 1005 vorhanden. Das hat recht lange gute Dienste geleistet, seit dem letzten Umzug funktioniert es leider nicht mehr. Ich habe noch nicht mal die geringste Idee, wo und ob man so ein altes Teil heute noch reparieren lassen kann, eine Neuanschaffung würde ich im Moment noch vermeiden wollen so möglich. So ganz billig ist ein gutes Oszilloskop ja leider nicht. ;) Aber nun zum eigentlichen Ursprungsthema: Ich habe versucht eure Beiträge von oben nach unten durchzuarbeiten, habe das bis jetzt aber leider noch nicht ganz geschafft. Ich wollte jetzt aber mal eine Antwort schreiben, nicht dass ihr denkt, ihr habe eure Zeit verschwendet. Nach meinem aktuellen Stand tendiere ich stark in Richtung Atmel AVR. Man findet schon hier sehr viel Information und wenn man mit den Infos ein bisschen weitersurft kaum erfassbare Mengen an weiteren. An der Stelle hänge ich auch gerade und vielleicht könnt ihr mir da nochmal ein Stückchen weiterhelfen. Unabdingbar ist für die Programmierung die Verwendung eines PC. "Leider" habe ich dieses Jahr den kompletten Bestand bei uns ausgemistet und durch neue Maschinen ersetzt. So dass aktuell nur eine Xeon Workstation (Win 7 ultimate 64-bit) und zwei Notebooks (Corei5/i7 Win8 64bit) vorhanden sind. Was einerseits hardwareseitig zu Problemen führt - außer USB keine "brauchbare" Schnittstelle zur Außenwelt vorhanden, anderseits scheint es mir in Sachen Compiler so zu sein, dass es keinen !?! gibt, der 64bit tauglich ist. Kann das wirklich sein? Oder bin ich nur noch nicht auf den richtigen gestoßen? In Sachen Hardware bin ich noch ziemlich "blank". Ich habe z.B. den Unterschied zwischen Programmerboard und Evalboard noch nicht begriffen. Eigentlich brauche ich doch "nur" ein Gerät mit dem ich das geschriebene und compilierte Programm auf den Controller schreiben kann. Diesen setze ich dann in "meine" Schaltung ein, wo er dann tut was er tun soll - oder nicht? Auch noch nicht im Klaren bin ich mir darüber, ob ich mit einem "reinen" AVR besser oder schlechter fahre als mit einem Arduino (oder Derivat). Früher war ich in C mal gar nicht so schlecht, zumindest hat es in der Windowswelt zum Schreiben einiger (kleiner) Erweiterungen für CATIA V5 gereicht. Ich fand bisher eigentlich auch die Entwicklung eines Algorithmus deutlich aufwendiger als diesen dann in Code umzusetzen. Von daher wäre mir die Programmiersprache erstmal egal, solange das nicht doppelt Lernen erst für den Einstieg und dann für später bedeutet. Wenn ihr mir hier noch ein wenig weiterhelfen könntet wäre mir sehr geholfen. Ciao, Stefan [Edit] Glatt vergessen: Ich bin keineswegs im Rentenalter, bis dahin habe ich noch gut 20 Jahre. Ich gehöre zu den glücklichen Menschen, die nicht fürs Arbeiten bezahlt werden sondern dafür, dass sie ihrem Hobby frönen. Ich verdiene mein Geld im Bereich Automotive nach einer Phase in der CAx-Methodik Powertrain heutzutage mit der Entwicklung von Karosserierohbauten. Privat bin ich immer noch mehr den Motoren, Getrieben und Fahrwerken verbunden was an meiner Ausbildung liegen mag. Schrauben kann ich, Spenglern nicht. ;) Ein Maschinenbaustudium habe ich auch mal hinter mich gebracht, grundsätzliches technisches Verständnis sollte also durchaus einigermaßen vorhanden sein. [/Edit]
:
Bearbeitet durch User
Stefan Tully schrieb: > Unabdingbar ist für die Programmierung die Verwendung eines PC. "Leider" > habe ich dieses Jahr den kompletten Bestand bei uns ausgemistet und > durch neue Maschinen ersetzt. So dass aktuell nur eine Xeon Workstation > (Win 7 ultimate 64-bit) und zwei Notebooks (Corei5/i7 Win8 64bit) > vorhanden sind. Was einerseits hardwareseitig zu Problemen führt - außer > USB keine "brauchbare" Schnittstelle zur Außenwelt vorhanden, anderseits > scheint es mir in Sachen Compiler so zu sein, dass es keinen !?! gibt, > der 64bit tauglich ist. Kann das wirklich sein? Oder bin ich nur noch > nicht auf den richtigen gestoßen? Die nativen seriellen Schnittstellen sind an PCs und Notebooks mittlerweile ausgestorben, das stimmt. Allerdings gibt für wenige Euro USB-RS232-Adapter bzw. USB-TTL-UART-Adapter. Damit kann man sehr einfach eine Verbindung zu einem Mikrocontroller herstellen und z.B. Textnachrichten in einem Terminalfenster übertragen. Aber auch ein Programm auf dem PC zu schreiben, das einen seriellen Port öffnet und darüber Daten mit dem Mikrocontroller austauscht, ist kein Hexenwerk. Einen "64-bit tauglichen" Compiler brauchst Du nicht, da Windows x64 ja weiterhin 32-Bit-Anwendungen ausführen kann. AVR-Studio 6 mit dem AVR-GCC läuft z.B. einwandfrei unter Windows 7 x64. Die Zielplattform ist ja sowieso eine ganz andere (bei AVRs 8 Bit). ;-) > In Sachen Hardware bin ich noch ziemlich "blank". Ich habe z.B. den > Unterschied zwischen Programmerboard und Evalboard noch nicht begriffen. > Eigentlich brauche ich doch "nur" ein Gerät mit dem ich das geschriebene > und compilierte Programm auf den Controller schreiben kann. Diesen setze > ich dann in "meine" Schaltung ein, wo er dann tut was er tun soll - oder > nicht? Es gibt mehrere Möglichkeiten. 1. Ein reines Experimentierboard, auf das ein Mikrocontroller fest aufgelötet ist. Darunter fallen z.B. die Arduinos. Du bekommst ein fertiges Board mit ein paar IO-Pins, das Du per USB an den PC anschließt und direkt loslegen kannst. Dieses Board ist dann schon "deine Schaltung", die Du über die externen Pins erweitern kannst. 2. Ein Evaluationsboard, mit Sockeln, in die man temporär einen Mikrocontroller steckt. Darunter fällt z.B. das STK 500 von Atmel oder das Pollin-Board. Den Mikrocontroller in dem Sockel kann man ebenfalls über den PC programmieren, außerdem gibt es auf dem Board ein paar Taster, LEDs etc. mit denen man experimentieren kann. Man kann so ein Board auch benutzen, um den Mikrocontroller im Sockel zu programmieren und in seine Zielschaltung einzusetzen. 3. Ein In-System-Programmer (ISP), z.B. der Atmel ISP mkII. Das ist ein reines Programmiergerät, mit dem man den Mikrocontroller direkt in der Zielschaltung programmieren kann. Du baust also von Anfang an Deine eigene Schaltung mit dem Mikrocontroller auf und schließt das Programmiergerät nur temporär über die entsprechenden ISP-Pins an, um eine neue Software aufzuspielen. > Auch noch nicht im Klaren bin ich mir darüber, ob ich mit einem "reinen" > AVR besser oder schlechter fahre als mit einem Arduino (oder Derivat). Vielleicht fällt Dir die Entscheidung jetzt leichter. Beim Arduino bekommst Du ein fertiges Board, das sicher funktioniert und eine sehr einfache Entwicklungsumgebung. Du wirst also sehr schnell ein Erfolgserlebnis haben. Allerdings ist der Mikrocontroller "untrennbar" mit dem Arduino-Board verbunden. Ein Evalboard mit AVR funktioniert auch recht sicher, allerdings gibt es schon mehr Freiheitsgerade und damit mehr Fehlerquellen (richtiger Sockel, richtiger Port, Jumperkabel, IDE richtig einstellen etc.) und die Programmierung ist hardwarenäher, Du wirst also eher mal ins Datenblatt des Mikrocontrollers schaun müssen, da es keine Abstraktionsschicht-Software wie beim Arduino gibt. Wenn Du direkt eine eigene Schaltung aufbaust gilt das gleiche, es kommen aber eben noch ein paar Fehlerquellen beim Aufbau der Schaltung dazu. Wenn man klein mit einem Steckbrett und ein paar LEDs anfängt und es nicht sofort in die Ecke schmeißt, wenn es nicht gleich auf Anhieb funktioniert, aber alles nichts unschaffbares. > Früher war ich in C mal gar nicht so schlecht, zumindest hat es in der > Windowswelt zum Schreiben einiger (kleiner) Erweiterungen für CATIA V5 > gereicht. Ich fand bisher eigentlich auch die Entwicklung eines > Algorithmus deutlich aufwendiger als diesen dann in Code umzusetzen. Von > daher wäre mir die Programmiersprache erstmal egal, solange das nicht > doppelt Lernen erst für den Einstieg und dann für später bedeutet. Na dann stellt sich die Frage nach der Programmiersprache doch gar nicht, nimm C. Darunter fällt auch die "Arduino-Programmiersprache", die nichts anderes als C++ ist. Das einzige was Du lernen musst, ist der grundsätzliche Aufbau von Mikrocontrollerprogrammen (Initialisierung, Hauptschleife, Interrupts) und die Hardwareansteuerung (d.h. entweder die Bedeutung der Register aus dem Datenblatt lernen bzw. wie man die Arduino-Funktionen verwendet). > Glatt vergessen: > Ich bin keineswegs im Rentenalter, bis dahin habe ich noch gut 20 Jahre. > Ich gehöre zu den glücklichen Menschen, die nicht fürs Arbeiten bezahlt > werden sondern dafür, dass sie ihrem Hobby frönen. Ich verdiene mein > Geld im Bereich Automotive nach einer Phase in der CAx-Methodik > Powertrain heutzutage mit der Entwicklung von Karosserierohbauten. > Privat bin ich immer noch mehr den Motoren, Getrieben und Fahrwerken > verbunden was an meiner Ausbildung liegen mag. Schrauben kann ich, > Spenglern nicht. ;) Ein Maschinenbaustudium habe ich auch mal hinter > mich gebracht, grundsätzliches technisches Verständnis sollte also > durchaus einigermaßen vorhanden sein. Nach dem was Du so schreibst, habe ich den Eindruck, dass Du keinen Arduino brauchst, sondern mit einem reinen AVR + Programmer und/oder Entwicklungsboard mit Atmel Studio sehr gut zurecht kommen wirst.
Besser und günstiger als die avr: http://www.ti.com/lsds/ti/microcontroller/16-bit_msp430/overview.page Aber heute nimmt man ARM: http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/LN1199/PF259100?s_searchtype=partnumber (avr war gestern) :-P
Hans schrieb: > Allerdings ist der Mikrocontroller "untrennbar" > mit dem Arduino-Board verbunden. Das ist nicht ganz richtig. Es gibt Arduino-Boards, auf den ein AVR im SMD-Gehäuse aufgelötet ist. Das finde ich nicht gut, da der freigewordene Platz überhaupt nicht benötigt bzw. benutzt wird. Daher mein Rat, ein Board mit gesockeltem ATmega328 im DIL28-Gehäuse zu nehmen. Hans schrieb: > Nach dem was Du so schreibst, habe ich den Eindruck, dass Du keinen > Arduino brauchst, sondern mit einem reinen AVR + Programmer und/oder > Entwicklungsboard mit Atmel Studio sehr gut zurecht kommen wirst. Das mag so sein; andererseits ist mit der fertigen Lösung der Einstieg sehr einfach und es gibt auch die Möglichkeit, das Arduino-Board anschließend als ISP-Programmiergerät zu verwenden. Damit kann man dann AVRs in anderen/eigenen Schaltungen programmieren. Zur Stückliste: Steckbretter und damit verbundene Stiftleisten und Kabel habe ich nie benutzt. Als Probeaufbau kann man auch dreidimensionale Gebilde zusammenlöten, die u.U. noch einen bleibenden künstlerischen Wert behalten :-) m.n. schrieb: > Alle Vorschläge, die zum ARM als Einstiegsprozessor raten, solltest Du > völlig ignorieren. Das wurde ja schon geschrieben.
Stefan Tully schrieb: > Hallo zusammen, > herzlichen Dank für die Vielzahl an umfassenden Antworten. Ihr habt mir > schon jetzt sehr weitergeholfen. > Für mich inzwischen klar: Ich muss den Elektronik Einsteig gleich > mitmachen. Dazu braucht es die entsprechende Grundausstattung. Ich habe > mal ein Excel angehangen, was ich mir besorgen würde. Bei den Bauteilen >... Mein Gott, in der Zeit die du bis jetzt für Recherchen verplempert hast haben andere schon lange angefangen und die ersten selber gelöteten Platinen im Einsatz und ohne den ganzen Kram (Oszi,...) der bei dir schon rumsteht. Das sind ja echte Luxusproblem die du hast. Ich glaube du sitzt in einem Jahr noch am Schreibtisch und überlegst dir was du jetzt kaufen sollst.
Ich nutze sehr gerne einen ARM (bzw den STM32), würde den auch empfehlen, aber da Stefan Tully ein absoluter "neueinsteiger" ist, kann ich den für ihn persönlich nicht empfehlen. Ein Arduino oder ein AVR ist die Richtige Wahl.
:
Bearbeitet durch User
Stefan Tully schrieb: > Hallo zusammen, > ich bin absoluter Neueinsteiger in die Welt der Elektronik und > Mikrocontroller Programmierung. Ein bisschen Programmierung habe ich in Ich würd ihm erstmal raten mit den Basics der Elektronik anzufangen. Ohmsches Gesetz und so. Mit Multimeter messen und Vorwiderstände von LEDs zu berechnen, Transistoren himmeln bevor die Fragen kommen, wieviel Ausgangsstrom denn ein STM32-Pin ab kann vielleicht auch noch Datenblattenglisch zu lernen.
Zum Beispiel ein Kosmos Elektronik Kasten. Alles gut beschrieben.
Hans schrieb: > Nach dem was Du so schreibst, habe ich den Eindruck, dass Du keinen > Arduino brauchst, sondern mit einem reinen AVR + Programmer und/oder > Entwicklungsboard mit Atmel Studio sehr gut zurecht kommen wirst. Das sehe ich eigentlich genau so. Der Vorteil des Arduino liegt darin, dass es alles sehr preiswert und schnell beschaffbar ist. Einfach mal in der Bucht "Arduino Uno" eingeben und sich was passendes aussuchen. Da der Uno einen Prozessor im gesockelten DIL benutzt, kann man den auch preiswert ersetzen, wenn es mal "knallt". Auch das Umsetzen auf das Breadboard ist damit trivial. Zusätzlich würde ich auch den MK-II Programmer empfehlen. Der past auch an den Arduino Uno. Dann kann man mit dem Atmel-Studio den Prozessor auch "bare metal" programmieren, falls einem die Arduino Software nicht gefällt. Ansteuerboards für Motoren, LCD usw. gibt es dazu auch. Wie gesagt: Einfach mal in der Bucht stöbern gehen. Ansonsten sieht Dein Bestellzettel für den Anfang ziemlich vollständig aus. Allerdings sind solche Listen NIE vollständig ;-) Das Netzteil würde ich noch einmal überdenken. Mit nur einer Spannung kann man keine symetrischen Versorgungen aufbauen (z.B. -15V,0V,15V), die man gelegentlich braucht. Für die Cs/Rs solltest Du mal schauen, ob Du mit fertigen Sortimenten nicht preiswerter fährst. Reichelt und die Bucht haben da z.B. ganz brauchbare Angebote. Grüße Andreas P.S: Das "PC Interface Problem" kann man heute relativ schnell mit entsprechenden USB Adaptern lösen, z.B. (Für RS232) http://www.ftdichip.com/Products/Cables/USBRS232.htm Entsprechende Adapter gibts da auch für paralleles IO. FTDI liefert auch sehr schnell an Provatkunden über den WEB Shop. A.
Hallo zusammen. @ Stefan: Sieh dir doch mal diese Seite an: http://www.rowalt.de/ Ein Buch, dazu gehört ein Experimentierboard. Dieses Board ist als Bausatz bei SEGOR erhältlich. http://www.segor.de/#Q%3DAVR-Lehrbuch%25252FTeilesatz%26M%3D1 Löten kannst du ja, und auch mit einem ERSA30 wirst du dieses Teil zusammen gelötet bekommen. Dazu brauchst du noch einen Programmer. Das wäre erst mal ein Anfang. Die C-Leute schreien jetzt natürlich sofort: IHHHH.... BASIC. In jeder Sprache kann man unleserlichen Code schreiben.... Ich bin mit Board und Buch bestens zurecht gekommen; das hat mir meinen Einstieg sehr leicht gemacht. 73 Wilhelm
Achtung: Aus dem Segor-Link kommt man nicht mehr zurück! 73 Wilhelm
Wilhelm Schürings schrieb: > Das wäre erst mal ein Anfang. > Die C-Leute schreien jetzt natürlich sofort: IHHHH.... BASIC. > In jeder Sprache kann man unleserlichen Code schreiben.... ... und das besonders in C :-) :-) :-)
Die erste Frage, die du dir stellen solltest ist, natürlich neben dem "was will ich überhaupt erreichen (können), die, in welcher Programmiersprache du arbeiten möchtest. Ich denke es gibt die folgenden Optionen: - Hardwareferne bzw. -fernere Sprachen wie Python oder Arduino C++. Vorteil: Viele Details bleiben dir verborgen, du kannst schnell zu Ergebnissen kommen. Nachteil: Irgendwann willst du wahrscheinlich irgendetwas realisieren, was nicht in den Standard-Bibliotheken vorgesehen ist. Dann musst du selbst Hand anlegen in C/C++. Und: Hier verbrätst du einiges an Hardware-Performance, durch die Bibliotheken bzw. ein Betriebssystem. Du hast also etwas weniger Kontrolle über die Hardware. - Bascom wäre, so weit ich das sehe, ich nutze es nicht, ein Zwischending. Ich würde vermuten, es gibt dazu etwas weniger Support auf Websites und im Forum. Die Möglichkeiten dürften etwas erhöht zu den erstgenannten sein, aber man erkauft sich auch etwas Inflexibilität, da es denke ich nicht so viele Bascom taugliche Entwicklungsumgebungen etc. gibt. Ich finde den Trade-Off "Etwas mehr Flexibilität" gegen "Deutlich schlechterer Support" nicht lohnenswert. Aber mach dich selbst schlau. - Programmierung in C/C++: Wie oben schon gesagt, recht verbreitet und daher gibt es jede Menge Unterstützung, Tutorials etc. Auch viele Bibliotheken für Standardprobleme sind verfügbar (siehe u.a. Link unten). C/C++ gibt es auch für jede Plattform. Ob du einen Atmel Microcontroller oder einen von NXP programmieren willst: Es geht mit C/C++. Außerdem hast du alles von in der Hand, kein Betriebssystem funkt dazwischen (außer du nutzt doch eines ;) Nachteil: Ja, gerade in C kann man wirklich unsauber programmieren. Aber da muss man sich am Riemen reißen und sauber programmieren. - Programmierung in Assembler: Für mich, bis auf Spezialprobleme, eigentlich keine Option mehr. Einfache Dinge sind in Assembler einiges an Aufwand. Man muss u.a. Statusregister des Prozessors auslesen etc. Während ich in einer Hochsprache einfach a = b + c schreibe, muss ich das in Assembler ggfs. in mehrere Zwischenoperationen zerlegen und dann noch z.B. in den Statusregistern des Prozessors nachschauen, ob bei der Addition z.B. ein Overflow aufgetreten ist. Ein Vorteil ist natürlich, dass du jede Operation des Prozessors in der Hand hast. Das erkauft man sich aber recht teuer. Kommentare im Code sind absolut Pflicht, da man die Operationen nicht einfach nachvollziehen kann, und Variablennamen vergeben kann man auch nicht. Man muss auch wissen, in welches Register man zum gegeneben Zeitpunkt welche Variable vorhält. Das ganze Registermanagement hat man damit auch am Hals. Eine Hochsprache nimmt einem das alles ab. Ein Vorteil ist vielleicht noch, dass man die Prozesse in der Tiefe versteht. Das ist durchaus hilfreich für jede Programmierung, überfordert aber am Anfang denke ich. Dann zur Hardware: - Willst du in Python programmieren, brauchst du einen Raspberry Pi. Super Ding, einfach zu programmieren, ist aber mit Kanonen auf Spatzen geschossen, wenn du nur z.B. eine LED blinken lassen willst. - In Arduino kannst du schnell loslegen, es gibt auch eine gute Unterstützung für vieles. Aber: Die begrenzten Möglichkeiten können schnell einbremsen. Das hängt halt davon ab, was du machen willst. - Bascom ist glaub ich ein Ding, was auf Atmel 8-Bittern hauptsächlich läuft. Kann man machen, aber ich würde eher abraten. - Willst du in C/C++ programmieren, kannst du fast alles nehmen. - Willst du in Assembler programmieren, kannst du theoretisch auch fast alles nehmen. Praktisch solltest du dich auf echt einfache Hardware wie z.B. die 8-Bit uCs von Atmel, beschränken, da es sonst viel zu komplex von der Programmierung wird. Ich würde dir allerdings von einem 8-Bit uC abraten. Dagegen sprechen die begrenzteren Möglichkeiten. Es kamen ja schon Kommentare, dass die 8-Bitter auf jeden Fall reichen, und ja, ich weiß, man muss keinen USB Stick oder Netzwerk an seinen Mikrocontroller anschließen, aber dass man es kann, ist super. Man hat mal schnell einen MP3 Player gebastelt oder speichert Daten auf dem Stick etc. Das ist einfach super. Vorallem spricht für mich aber das schlechtere Debugging gegen z.b. die 8-Bit Atmegas. Will ich meinen Code auf Fehler analysieren, ist es sehr hilfreich, einfach einen Breakpoint in der Entwicklungsumgebung setzen zu können und durch mit dem Mauszeiger über die Variable fahren lesen zu können, welchen Wert sie hat. Bei den 8-Bittern geht das meist nicht direkt und ich muss eigens Code schreiben, der mir entweder LEDs zum blinken bringt oder ein Display für die Ausgabe anschließen. Das ist einfach zusätzlicher Aufwand, den man sich schenken kann. Mein Tipp daher: Fang mit einem STM32F4 Discovery Board an. Das hat mehrere Gründe - Günstig (ca. 15€, ein Programmieradapter ist mit drauf. Nur noch ein Mini-USB Kabel dazu, dann geht es los) - Es gibt super Entwicklungsumgebung mit CooCox IDE (www.coocox.org), die einfach zu installieren ist - Es gibt eine aktive Community und jede Menge Beispielprojekte (guck z.B. mal bei http://mikrocontroller.bplaced.net/). Mit den Beispielen lässt sich viel erreichen, wie mit dem Mikrocontroller generell. Von da aus kann man dann seine eigenen Schritte gehen. Programmieren müsstest du allerdings in C/C++. Da es aber viele Beispiele gibt, denke ich kann man da recht gut reinkommen. Ich hoffe das hilft dir. Liebe Grüße, Jan
Angehängte Dateien:
-
DISCO.jpg
100 KB
Ich schlage auch etwas vor, STM32F4 DISCOVERY STM32F429 TFT LCD 32 Bit mit Bildschirm und Kommunikation zur Entwicklungsumgebung COOCOX mit DEBUG. Zwei LED für erste Versuche. Viele Schnittstellen und gute Dokumentation vom Hersteller des Boards. Mit einem Breadboard for Arduino und anderen Kleinkram sind Erweiterungen möglich. Auf dem Bildschirm ist ein Hintergrundbild sichtbar. Es ist viel Hardware auf dem Board vorhanden, die nutzbar ist.
Stefan Tully schrieb: > Für mich inzwischen klar: Ich muss den Elektronik Einsteig gleich > mitmachen. Dazu braucht es die entsprechende Grundausstattung. Ich habe > mal ein Excel angehangen, was ich mir besorgen würde. Bei den Bauteilen > selbst habe ich mich nach dem "Absolute Beginners" Artikel hier > gerichtet, bei den Stückzahlen habe ich, wie jedem erfahrenen sicherlich > sofort auffällt, einfach mal ins Blaue geraten. Es würde mich sehr > freuen, wenn sich jemand die Mühe machen würde und mal einen Blick auf > die Liste wirft und korrigierend eingreift wo notwendig. Hängt ja immer davon ab, was man später mal macht :oD :oD ;oD Ich habe jetzt mal darübergesehen und meine Anmerkungen dazu geschrieben. Übrigens habe ich den Eindruck gewonnen, dass Du Dir hier eher mal zuviel Gedanken machst. IMHO bist Du inzwischen schon bereit um zu bestellen und erstmal loszulegen. Irgendetwas fehlt ja immer ;o) Steckbrett: IMHO beste Qualität, Super wenn Du viel Platz hast in Deiner Bastel-Ecke, ansonsten reicht auch ein halb so grosses lange Zeit aus. Bei Gelegenheit vielleicht auch noch ein paar billige kleinere mit z.B. 270 Kontakten kaufen, ich lasse darauf manche Schaltungen gerne mal stehen. Manche Bauteile kann man auch in das Steckbrett reinquetschen, es wird dadurch aber beschädigt oder unzuverlässig und da nehme ich auch immer die günstigen. http://www.conelek.com/Elektronik-Laborbedarf-58/Steckplatinen/Standard-Line-SYB/-p-Steckplatine-270-Kontakte-SYB46-br-----p-.html Fehlt noch: Verbindung von den 4mm Bananenbuchsen auf die einzelnen Stromversorgungszeilen des Steckbretts: http://www.conelek.com/Elektronik-Laborbedarf-58/Laborkabel/0-6mm/Testkabel-flexibel-PIN---Y-Anschluss-100-mm--TS100PY.html Drahtbrücken: Hier würde ich zu dem grösseren und vor allem übersichtlich sortiertem Set raten, fand ich deutlich besser als das Kleine: http://www.conelek.com/Elektronik-Laborbedarf-58/Drahtbruecken/Drahtbruecken--fuer-Steckplatinen-Set---350-Stueck-KS350.html Laborkabel 4mm: Vielleicht doppelt soviele bestellen? Widerstände: Vielleicht doch noch ein Sortiment von Vellemann? Bei Reichelt "K/RES-E3" und/oder "K/RES-E12". Falls Geld keine Rolle spielt - Reichelt führt auch die Sortimente des komfortablen Comp-Card-Systems, z.B.: Metallschicht E24 von 1R bis 1M (10 Stück je Wert) für 67,75 EUR Potis: Du hast hier Trimmer (nur mit Schraubenzieher oder "Trimmbesteck" einzustellen.) im Focus. Am Anfang sind vermutlich eher die Potis die mit der Hand verstellt werden gemeint (z.B. Reichelt PO6M-LIN 1,0M): Da gibt es sogar ein erwähnenswertes Pollin-Sortiment (wobei man da nie wissen kann, was man bekommt - Überraschungspaket) http://www.pollin.de/shop/dt/MzY5OTkxOTk-/Bauelemente_Bauteile/Sortimente/Passive_Bauteile/Potentiometer.html Da Du bei Widerständen, ElKos, LEDs, KerKos und Transistoren nicht zu den Vellemann-Sortimenten greifst und lieber einzelne Werte bestellst, hast Du dir ja sicherlich schon viele Gedanken darüber gemacht. Wir wollen es ja übersichtlich gestalten: Taugt schon für den Einstieg. OPV und 555: Da reichen ein paar wenige (2-3?) für den Einstieg, ansonsten würde ich ICs später immer nach Interesse bzw. Bedarf bestellen. Habe auch ganz viele Logik-Gatter-ICs gekauft. Aber die Einsteigerexperimente waren dann so witzlos, dass man das nichtmal mehr aufgebaut hat. Zu jedem IC auch zwei low-cost IC-Fassungen mitbestellen. Die Präzisionssockel halten nicht im Steckbrett und man kann am Anfang (wenn man noch unsicher ist) auch doppelt gesockelt arbeiten. Später erkennt man, dass man vielleicht bisher zu vorsichtig war und die Viecher mehr aushalten, als man zunächst gedacht hatte. Schalter/Taster Die Taster sind interessant am Anfang, aber von den teuren Schaltern vielleicht erstmal nur zwei kaufen. Die Umschalter braucht man erstmal kaum und in ein paar Wochen findest Du viel günstiger Quellen :o) Stiftleisten neben Stiftleisten auch wenige Buchsenleisten und Präzisionsbuchsenleisten bestellen. Teuer aber sehr universell sind die Reichelt MPE 115-1-036 . Kann man alle mal brauchen. Was könnte noch fehlen? Klemmprüfspitzen mit Messleitung mit so kleinen Haken um z.B. einzelne IC-Pins abzugreifen http://www.conelek.com/Elektronik-Laborbedarf-58/Klemmpruefspitzen/Klemmpruefspitzen-mit-Messleitung-5-Paar-5-Farben-37cm-PL15.html Klingeldraht divers Farben: selbst Verbindungen für Steckbrett oder Lochraster konfektioneren http://www.conelek.com/Elektronik-Laborbedarf-58/Drahtbruecken/Schaltdraht---Y-Draht---Klingeldraht-0-6mm-Durchmesser-10m--rot--schwarz--gelb--blau--weiss-103459.html Flexible Drahtbrücken mit runden Kontakt (billig und ideal für Buchsenleiste mit Präzisionskontakt, für Steckbrett auch ok) http://www.conelek.com/Elektronik-Laborbedarf-58/Laborkabel/0-6mm/Testkabel-flexibel-Pin-d-0-6-mm---Pin-d-0-6-mm-ca--75-St--verschiedene-Farben-verschiedene-Laengen--103436-3096.html Piezo Schallgeber? http://www.conelek.com/Bauteile-Bauelemente/Elektromechanische/Summer/Piezo-Element-24mm-6kHz-90dB-103434.html Lochraster und Streifenraster Platinen Schrumpfschläuche Folienkondensatoren, da ist auch das "Pollin-Sortiment" interessant zum basteln Adernendhülsen Abbiegevorrichtung für Widerstände u.a. http://www.conelek.com/Elektronik-Werkstatt/Loeten/Zubehoer-122/Abbiegevorrichtung-fuer-Rastergroessen-7-5mm---17-5mm-ABV.html
Stefan Tully schrieb: > Für mich inzwischen klar: Ich muss den Elektronik Einsteig gleich > mitmachen. So habe ich Dein erstes Posting auch verstanden. Ich denke aber, inwischen hast Du Dich schon für die erste Bestellung ausreichend intellektuell vorbereitet. Inzwischen kannst Du wirklich den Anfang wagen. Dazu braucht es die entsprechende Grundausstattung. Ich habe > mal ein Excel angehangen, was ich mir besorgen würde. Bei den Bauteilen > selbst habe ich mich nach dem "Absolute Beginners" Artikel hier > gerichtet, bei den Stückzahlen habe ich, wie jedem erfahrenen sicherlich > sofort auffällt, einfach mal ins Blaue geraten. Es würde mich sehr > freuen, wenn sich jemand die Mühe machen würde und mal einen Blick auf > die Liste wirft und korrigierend eingreift wo notwendig. Wie gesagt, Du kannst schon anfangen in meinen Augen. Gewisse Fehlkäufe lassen sich nicht vermeiden und irgendwas hat man sowieso übersehen. Ich bin mal meine ersten Bestellungen mit Deiner Liste durchgegangen (siehe oben) und das taugt schon. Aber da Verzettelt man sich halt ganz gerne, IMHO ist deine Anfangsbestellung durchaus brauchbar. Z.B. würde ich jetzt weniger PNP-Transistoren nehmen. Aber bei 4 Cent pro sollten wir uns keine Gedanken darüber machen und ich möchte auch die Vorwürfe vermeiden, wo Dir mal genau diese 10 PNP-Transistoren dann wirklich mal fehlen ;oD > An Werkzeug möchte ich erstmal nichts zukaufen. Ich habe schon lange ein > Metex 3640 (Multimeter) bis jetzt hat das für mich immer gereicht, ich > hoffe, das tut es für dein Einstieg in die Elektronikwelt auch. Kauf Dir noch zwei kleine Billig-Multimeter (<<10 EUR) dazu. Ideal wären vielleicht welche wo man zwischen Spannung- und Strom-Messung nicht umstecken muss. > Lötkolben habe ich aktuell so ein Teil: wird schon taugen (kenne den Lötkolben nicht). Neben den Lötkolben braucht man ja noch Lötzinn 1mm, manchmal Entlötlitze und vielleicht noch extra Flussmittel aka Löthonig (Z.B. 20g Kolophonium -Pollin 840041- in 100 mL Ethanol auflösen). > Aber nun zum eigentlichen Ursprungsthema: > ... > Nach meinem aktuellen Stand tendiere ich stark in Richtung Atmel AVR. > Man findet schon hier sehr viel Information und wenn man mit den Infos > ein bisschen weitersurft kaum erfassbare Mengen an weiteren. > An der Stelle hänge ich auch gerade und vielleicht könnt ihr mir da > nochmal ein Stückchen weiterhelfen. Fang doch einfach mit dem simplen AVR an und arbeite die Tutorials hier ab. Da ist halt die Dokumentation am besten, und bei Problemen kannst Du schnell Hilfe bekommen. Mach Dir da nicht soviele Gedanken, wenn Du Dich da ein bisschen eingearbeitet hast, kannst Du ganz schnell auf andere Systeme wechseln. > Unabdingbar ist für die Programmierung die Verwendung eines PC. "Leider" > habe ich dieses Jahr den kompletten Bestand bei uns ausgemistet und > durch neue Maschinen ersetzt. So dass aktuell nur eine Xeon Workstation > (Win 7 ultimate 64-bit) und zwei Notebooks (Corei5/i7 Win8 64bit) Das kann schon ein paar Zicken machen. Bei meinem Umstieg auf Win 7 mit 64bit ist erstmal gar nichts gelaufen. Jetzt tut es aber. > In Sachen Hardware bin ich noch ziemlich "blank". Ich habe z.B. den > Unterschied zwischen Programmerboard und Evalboard noch nicht begriffen. > Eigentlich brauche ich doch "nur" ein Gerät mit dem ich das geschriebene > und compilierte Programm auf den Controller schreiben kann. Diesen setze > ich dann in "meine" Schaltung ein, wo er dann tut was er tun soll - oder > nicht? Ich habe ja mit einem Pollin-Board und einem usbasp-Programmer angefangen... Das eine ist halt die Beispiel-Schaltung wo der Mikrocontroller sitzt und mit LEDs und Tastern (und Sensoren) verbunden ist. Das andere ist die Programmierung des Mikrocontrollers. Natürlich könnte man in immer aus der Schaltung herausnehmen und im Programmiergerät neu flashen, aber es gibt ja auch z.B. ISP. Da liegt auf der Schaltung/der Platine ein Anschluss für den Programmer und Du kannst dann den Mikrocontroller so das neue Programm hochladen. > Auch noch nicht im Klaren bin ich mir darüber, ob ich mit einem "reinen" > AVR besser oder schlechter fahre als mit einem Arduino (oder Derivat). > Früher war ich in C mal gar nicht so schlecht Die Entscheidung ist in meinen Augen sehr leicht. Ich kann zwar persönlich mit C nichts anfangen. Aber wenn Du C kannst: Kauf Dir ein paar ATmegas und mach die AVR-C-Tutorials hier durch. Einfacher geht es gar nicht, es ist gut dokumentiert und die Leute hier können Dir bei Problmene sehr schnell weiterhelfen. Dann kannst Du Dir noch immer darüber gedanken machen, ob eine andere Plattform nicht besser für Dich wäre. Attacke!!! Klaus
Autor: Klaus I. (klauspi) Datum: 25.12.2013 22:01 Klaus I. schrieb: > > Ich habe jetzt mal darübergesehen und meine Anmerkungen dazu > geschrieben. Sehr ordentlich!
Ich würde jetzt mit den 8 Bittern nicht mehr anfangen. Sondern direkt auf einen Arm Cortex gehen. Den STM oder die Ti Stellaris Reihe. Für beide gibt es günstig DevelBoards mit kompletten Entwicklungsumgebungen inklusive Debugger. Je nachdem welche IDE man sich aussucht sind dort Einschränkungen bei Codegröße vorhanden oder auch komplett frei. Diese Develboards haben dann auch Steckleisten an die man weitere Schaltungen anschließen kann. Die 8 Bitter haben nur noch einen (1) Vorteil. Das ist die verfügbare Gehäuseform. Obwohl ein SMD löten auch nicht so das unmögliche ist. Man brauch vielleicht etwas mehr Übung wie bei einem DIL Gehäuse.
Jan Berg schrieb: > Vorallem > spricht für mich aber das schlechtere Debugging gegen z.b. die 8-Bit > Atmegas. Will ich meinen Code auf Fehler analysieren, ist es sehr > hilfreich, einfach einen Breakpoint in der Entwicklungsumgebung setzen > zu können und durch mit dem Mauszeiger über die Variable fahren lesen zu > können, welchen Wert sie hat. Bei den 8-Bittern geht das meist nicht > direkt und ich muss eigens Code schreiben, der mir entweder LEDs zum > blinken bringt oder ein Display für die Ausgabe anschließen. Das ist > einfach zusätzlicher Aufwand, den man sich schenken kann. Prinzipiell hast Du da schon recht. Allerdings kommt man da früher oder spatter ja doch nicht mehr drum herum. Wenn Du z.B. bei einer Fehlersituation ein Scope/LA trigger musst um dann auf dem Board den Fehler suchen zu können. Nachteilig empfinde ich bei den 32-Bit CPUs, dass sie extreme viel (sinnvolle) Features haben, die einen Anfänger extreme verwirren können. Ich würde darum am Anfang immer einen 8-Bitter empfehlen. Grüße Andreas
Mein Gott, wenn ich lese, wie hier die AVRs wie sauer Bier angeboten werden, bekomme ich richtig Mitleid. Nimm ein Launchpad (oder Discovery Board) und starte von 0 auf 100. Beim AVR musst du durch das Tal der Tränen. Da kannst du gleich einen 68HC oder 8051 nehmen. :-((( Also starte mit ARM oder zur Not MSP430. Aber nicht mehr mit den abgehangenen AVRs oder ST8.
Andreas H. schrieb: > Nachteilig empfinde ich bei den 32-Bit CPUs, dass sie extreme viel > (sinnvolle) Features haben, die einen Anfänger extreme verwirren können. > > Ich würde darum am Anfang immer einen 8-Bitter empfehlen. Dann nimm doch 16Bit, das ist ein Kompromiss. ;-) Mal ehrlich: 32Bit ist nicht schwieriger als 8Bit. In einer Hochsprache merktst du das gar nicht. Aber nicht alle Architekturen sind gleich und schon gar nicht die Peripherie!
Ich kann diese Empfehlungen zu den Cortexen nicht verstehen. Offensichtlich seid ihr schon so lange vom Einstieg entfernt, dass ihr keine Erinnerung mehr daran habt, wie schwer der Einstieg mal gewesen ist, trotz der einfachen 8-bitter. Es sind nicht nur die vielen Bücher und Tutorials, auch sind es nicht allein die einfachen Gehäuseformen, die es erlauben es auf dem Steckbrett zu probieren, vor allem sind es erstmal die Anwendungen. Was machen wir denn zunächst Sinvolles? Ein Beispiel von mir: Ich habe jetzt für ein Behindertenfahrzeug eine kleine Steuerung gebaut, die die Freigabe der vorderen Gurtrollen für einen von mir gewählten Zeitraum frei gibt. Dafür brauche ich eigentlich nur einen Pin, es sind aber zwei, weil ich über eine Led anzeige, dass das Relais unterbrochen ist. Ein weiteres Beispiel ist eine Kühlung für meine Fritzbox. One-wire und einen Lüfter. Also auch nur zwei Pins. Diese Steuerung machte ich noch mit Arduino; Uno programmiert, uC auf die Platine und fertig. Mach das mal mit einem STM32.
F. Fo schrieb: > trotz der einfachen 8-bitter. Was ist denn an einem 16Bit µC schwieriger als am 8Bitter??? Ein MSP430 ist einfacher zu erlernen als ein AVR. Wenn man nur das Eien kennt, sollte man nicht vergleichen!!!
lutz h. schrieb: > Future schrieb: >> Also starte mit ARM > > Genau, so sind 35 Jahre Mikrokontrollerentwicklung nutzbar. Sch... Zitat. So kann man den Sinn verfälschen. Future schrieb: > Also starte mit ARM oder zur Not MSP430.
Future schrieb: > Mal ehrlich: 32Bit ist nicht schwieriger als 8Bit. In einer Hochsprache > merktst du das gar nicht. Aber nicht alle Architekturen sind gleich und > schon gar nicht die Peripherie! Willkommen in der Cortex Welt. Bekanntlich ist der Cortex NUR der Core (!!!), der selber schon in diversen Varianten existiert. Für Anfänger "völlig nachvollziehbar" ^^ Und das sich die Peripherie auch noch von Hersteller zu Hersteller (und teilweise auch innerhalb der herstellereigenen Serien) unterscheidet macht die Sache nicht einfacher. F. Fo schrieb: > Ich kann diese Empfehlungen zu den Cortexen nicht verstehen. > Offensichtlich seid ihr schon so lange vom Einstieg entfernt, dass ihr > keine Erinnerung mehr daran habt, wie schwer der Einstieg mal gewesen > ist, trotz der einfachen 8-bitter. Full ACK. Genau DAS ist der Punkt. Grüße Andreas
Andreas H. schrieb: > Willkommen in der Cortex Welt. Bekanntlich ist der Cortex NUR der Core > (!!!), der selber schon in diversen Varianten existiert. Für Anfänger > "völlig nachvollziehbar" ^^ > > Und das sich die Peripherie auch noch von Hersteller zu Hersteller (und > teilweise auch innerhalb der herstellereigenen Serien) unterscheidet > macht die Sache nicht einfacher. Und wie ist es bei AVR? Von wieviel Herstellern gibt es die? Aha nur von einem! :-((( Und die sind voll kompatibel, jeder hat die gleiche HW, AT90, Atiny, Mega, XMega??? Atme noch einmal tief durch. ;-)
Future schrieb: > Und wie ist es bei AVR? Von wieviel Herstellern gibt es die? Aha nur von > einem! :-((( > > Und die sind voll kompatibel, jeder hat die gleiche HW, AT90, Atiny, > Mega, XMega??? Aber hier ist die Architektur, inkl. Peripherie von einem Anfänger relative schnell zu durchschauen. Und welchen Anfänger interessiert die 2nd Source Frage ? Da gehts doch eher um die Menge der verfügbaren Resourcen, um mal schnell was "abschmulen" zu können, oder ? Wenn Du mal auf einem 32Bit uP spurious bugs durch falsche Irq-Prios gehabt hast, wirst Du das sicher auch keinem Anfänger mehr aufs Auge drücken wollen ;-) Hier gilt doch, wie so oft, das KISS Prinzip :-) Grüße Andreas
Andreas H. schrieb: > Und welchen Anfänger interessiert die 2nd Source Frage ? Das hast du ins Spiel gebracht. Andreas H. schrieb: > Wenn Du mal auf einem 32Bit uP spurious bugs durch falsche Irq-Prios > gehabt hast, wirst Du das sicher auch keinem Anfänger mehr aufs Auge > drücken wollen Und beim 8Bitter brauche ich mir um Interrupt-Prioritäten keine Sorgen zu machen??? Was bitte schön hat das alles mit der Bit-Breite zu tun???
Future schrieb: > Und beim 8Bitter brauche ich mir um Interrupt-Prioritäten keine Sorgen > zu machen??? > > Was bitte schön hat das alles mit der Bit-Breite zu tun??? Bei welchen 8-Bittern kannst Du die IRQ Prioritäten denn ändern, also z.B. USBIRQ höher/niedriger priorisieren als einen PCI ? Grüße Andreas
Andreas H. schrieb: > Bei welchen 8-Bittern kannst Du die IRQ Prioritäten denn ändern Ob ich sie ändern kann oder nicht ist doch völlig egal. Ich muss die Proiritäten kennen und mir über deren Auswirkungen bewusst sein!!! Und das hat immer noch nichts mit Bitt-Breite zu tun!!! (Gäghhnn)
Für Stefan Tully ist der AVR besser als der STM32 weil: - Peripherie ist viel schlanker und somit leichter zu verstehen - Die Doku ist kürzer - Es gibt nicht so viele Peripherie Module - Es gibt mehr Einsteiger Bücher und Tutorien - Er ist Mitte 40 und hat ansonsten keinerlei Kontakte zu Schulen oder anderen (außer Forum/Internet) - Er programmiert kein PC und es sind somit kaum Kenntnisse vorhanden - reines Hobby ohne Aussicht auf berufliche Nutzung Unwichtig ist: - 8, 16 oder 32 Bit - Interrupt System - Spannung 3,3V 5V - Assembler - DIP Gehäuse (STM32 Boards sind z.T. auch Steckbrettauglich) Bei anderen persönlichen Eigenschaften würde ich ebenfalls einen STM32 empfehlen, aber nicht bei ihm.
Markus Müller schrieb: > Unwichtig ist: > - 8, 16 oder 32 Bit > - Interrupt System > - Spannung 3,3V 5V Danke, Danke, Danke!!!
Future schrieb: > Ob ich sie ändern kann oder nicht ist doch völlig egal. Ich muss die > Proiritäten kennen und mir über deren Auswirkungen bewusst sein!!! Genau. Und das ist (nicht nur für Anfänger) einfacher, wenn sie durch das Design und nicht durch den Programmierer festgelegt sind. Dann kann da eben auch nichts schiefgehen. Anfänger haben genug andere "Baustellen". Wieviele sind den schon beim ATMEGA an _delay_ms() verzweifelt, weil sie die FCPU nicht #defined hatten ? (Da durch die includes dann ein default genommen wird, kommt ja auch keine Fehlermeldung, sondern nur eine längere Fehlersuche.) > Und das hat immer noch nichts mit Bitt-Breite zu tun!!! (Gäghhnn) Nein, direkt mit der Bitbreite natürlich nicht, sondern mit der durch die Strukturverkleinerung gegebenen Möglichkeit, mehr Features zu integrieren. Bau mal einen Cortex auf der Technologie eines ATMEGA (90nm vs 0.8um ?? Weiss es auch nicht genau). Das Ding hätte eine Kantenlänge von vermutlich 20mm. Grüße Andreas P.S: Future schrieb: > Ein MSP430 ist einfacher zu erlernen als ein AVR. Da muss ich Dir sogar mal recht geben. Nicht wegen dem lernen, sondern wegen dem benutzen. Ich habe letztens ein Miniprojekt von einem MSP430 auf einen ATMEGA runterportiert (der Kunde macht seine Boards damit) und war nur am Fluchen. A.
Ich habe vor vier Wochen mit den Mikrokontrollern angefangen, und finde es sehr praktisch mit diesem 32 bit DISCO Board zu arbeiten. Auf dem Mikrokontroller gleich einen Bildschirm mit einer Eingabemöglichkeit zu haben ist einfach praktisch. Wenn ich mich als Einsteiger auf Interrupt-Prioritäten konzentrieren möchte, kann ich diese Prioritäten bei 8- bit oder 32 bit entsprechend vergeben.
lutz h. schrieb: > Ich habe vor vier Wochen mit den Mikrokontrollern angefangen, und finde > es sehr praktisch mit diesem 32 bit DISCO Board zu arbeiten. Auf dem > Mikrokontroller gleich einen Bildschirm mit einer Eingabemöglichkeit zu > haben ist einfach praktisch. Das glaube ich sofort ;-) > Wenn ich mich als Einsteiger auf Interrupt-Prioritäten konzentrieren > möchte, kann ich diese Prioritäten bei 8- bit oder 32 bit entsprechend > vergeben. Bei welchen 8-Bit uPs geht das den ? Ich kenne das nur von den 32-Bittern. Oder was meinst Du ? Grüße Andreas
Andreas H. schrieb: > Und das ist (nicht nur für Anfänger) einfacher, wenn sie durch > das Design und nicht durch den Programmierer festgelegt sind. > Dann kann da eben auch nichts schiefgehen. ??? Ob ich das Vorgegebene lerne, oder es selbst vorgebe ist doch egal. Wahlfreiheit ist etwas sehr schönes. ;-) Andreas H. schrieb: >> Und das hat immer noch nichts mit Bitt-Breite zu tun!!! (Gäghhnn) > Nein, direkt mit der Bitbreite natürlich nicht, sondern mit der durch > die Strukturverkleinerung gegebenen Möglichkeit, mehr Features zu > integrieren. > Bau mal einen Cortex auf der Technologie eines ATMEGA (90nm vs 0.8um ?? > Weiss es auch nicht genau). Jetzt wird es noch spaßiger. Nicht mehr die Bit-Breite sondern der Fertigungsprozess ist für den Einstieg und Anfänger interessant??? Laß den Punsch stehen und schlaf dich richtig aus. ;-) Andreas H. schrieb: >> Ein MSP430 ist einfacher zu erlernen als ein AVR. > Da muss ich Dir sogar mal recht geben. Nicht wegen dem lernen, sondern > wegen dem benutzen. Auch für Lernende ist der MSP430 zugänglicher als die AVRs. Mit dem Launchpad und den diversen Booster-Packs ist der Einstieg einfacher und günstiger als mit AVRs. Aber das weisst du ja. ;-)
Im Beitrag: http://www.mikrocontroller.net/articles/Interrupt steht: Etwas komplexere Mikrocontroller oder große Prozessoren bieten verschiedene Interruptlevel (Stufen) an. Deshalb: Ist mit den Interrupts das Problem, dass der Programmablauf auch von Ereignissen und nicht nur vom Code gesteuert wird.
Future schrieb: > F. Fo schrieb: >> trotz der einfachen 8-bitter. > > Was ist denn an einem 16Bit µC schwieriger als am 8Bitter??? Ein MSP430 > ist einfacher zu erlernen als ein AVR. > > Wenn man nur das Eien kennt, sollte man nicht vergleichen!!! Gut, der MSP430 ist auch gut geeignet.
Ob der Fragesteller überhaupt alles lesen wird? So viele schreiben sooo viel! Wege nach Rom gibt es auch hier natürlich unzählige. Mein bescheidener Vorschlag: Einen Arduino Uno auf einem Breadboard bauen, und als Programmer einen fertigen Arduino Uno nehmen. Gründe: 1.Es gibt viel Literatur darüber, im Netz und als Buch. 2.Viele User können Dir bei Problemen helfen. 3.Durch den fertigen Arduino hast Du immer eine Referenz. 4.Es ist nicht zu schwer und der Lerneffekt ist groß. 5.Wenn Du die Firmware selber compilierst lernst Du auch viel über die Software.
Leonard schrieb: > Ob der Fragesteller überhaupt alles lesen wird? > So viele schreiben sooo viel! > Wege nach Rom gibt es auch hier natürlich unzählige. Da bist du nicht besser als die vielen anderen Schreiber. ;-) Leonard schrieb: > Mein bescheidener Vorschlag: > > Einen Arduino Uno auf einem Breadboard bauen, und als Programmer einen > fertigen Arduino Uno nehmen. Oder ein Launchpad. Da hast du alles in einem. ;-))) Und kostet nur einen Bruchteil. :-)))
Future schrieb: > Jetzt wird es noch spaßiger. Nicht mehr die Bit-Breite sondern der > Fertigungsprozess ist für den Einstieg und Anfänger interessant??? Oh man, noch mal ganz langsam, extra für Dich: Das was man heute an Komplexität bei 32 Bit uPs hat ist (meist) alter Kram, der schon >20 Jahre gemacht wird. Halt nicht auf einem einzelnen Chip. Schau Dir mal den Aufbau alter CPUs (z.B. VAX11-780 oder ähnliches) an. Da wird Dir viel bekannt vorkommen. Verteilt auf mehrere ICs. PC User kannten das ja meist (in ganz einfacher Form) vom 8087, dem mathematischen Coprocessor des IBM-PCs. Im Embeddedbereich war hier eine "natürliche" Grenze dadurch gesetzt, das die Kunden eben gerade nicht mehrere komplexe ICs auf der Platine miteinander verdrahten wollten. Durch die damals fertigbaren Strukturbreiten war aber die Anzahl der Gatter noch sehr beschränkt. Dementsprechend waren die Prozessoren auch sehr "übersichtlich" (aka einfach). Dementsprechend konnte man sich auch mal schnell in einen Prozessor einarbeiten und hatte nach wenigen Tagen auch Fehlersituationen relativ gut im Griff. Durch die verbesserte Fertigungstechnik konnte in den letzten Jahren aber die Strukturbreite immer weiter verkleinert werden. Dies ermöglichte es den Herstellern deutlich mehr Gatter, und damit Funktionalität, auf den Chip zu packen, was die Kunden natürlich gerne annahmen. Diese Komplexität ist aber natürlich nicht mehr so einfach zu handhaben. Darum wird die SW Entwicklung auch zunehmend durch entsprechende LIBs vom Hersteller unterstützt. Für "erfahrene" Entwickler ist das kein alzugrosses Problem. Die lernen Das als "Differenz" zu schon bestehendem Wissen. Die benutzen die LIBs auch selten als Blackbox, sondern schauen auch mal ins Datenblatt um zu gucken, was da gerade passiert. Wenn es jetzt zu Problemen kommt sind sie auch durch ihre Erfahrung gut in der Lage, die Fehler zu finden. Einsteiger haben aber jetzt plötzlich das Problem, dass alles von 0-Vorwissen aus stemmen zu müssen. Und wenn das erste Mal nicht etwas so läuft wie erwartet, dann ist das Dilemma da. Dann ist man nämlich schnell dabei auf Assemblerebene Fehler zu suchen, die durch das (falsch rpgrammierte) Zusammenspiel von Peripherie und Core zustandekommen (denk an mein IRQ-Prio Beispiel von oben). Und das alles ohne wenigstens etwas Erfahrung mit "überschaubaren" Prozessoren gesammelt zu haben. Solange man natürlich nur "Hello world" auf dem TFT des Kits ausgibt, wird dieser Fall eher selten auftreten^^ Und darum halte ich 32-Bit für Anfänger für ungünstig. Nun begriffen ? > Laß den Punsch stehen und schlaf dich richtig aus. ;-) Da ich keinen Alkohol trinke, stellt sich das Problem nicht. Aber eine Runde schlafen ist eine gute Idee. Die Sim ist auch durch :-) Grüße Andreas
Andreas H. schrieb: > Und darum halte ich 32-Bit für Anfänger für ungünstig. Nun begriffen ? Nein! Weil unbegründet und einfach nur behauptet. Nach deiner Argumentation müssten alle den Führerschein auf so einem Auto machen: http://www.deutsches-museum.de/typo3temp/pics/79179e0e95.jpg ;-)))
lutz h. schrieb: > Im Beitrag: > http://www.mikrocontroller.net/articles/Interrupt > > steht: > Etwas komplexere Mikrocontroller oder große Prozessoren bieten > verschiedene Interruptlevel (Stufen) an. Das kann sogar schon ein AT90 (ob man den allerdings als "complex" bezeichnen will ?). Mal aus dem Datenblatt von einem AT90USB162 (rein willkürlich, lag hier noch rum): "The complete list of vectors is shown in “Interrupts” on page 63. The list also determines the priority levels of the different interrupts." Interessant wirds, wenn Du diese Interruptlevel selber priorisieren kannst. > > Deshalb: > Ist mit den Interrupts das Problem, dass der Programmablauf auch von > Ereignissen und nicht nur vom Code gesteuert wird. In vielen Fallen ist das sogar der Zweck der Übung. Beispiel: Der Controller "reagiert" auf Änderungen der Umgebung (z.B. Spannungsänderung) und regelt sie nach (z.B. Änderung des Puls/Pause Verhältnisses der PWM, die die Spannung erzeugt), während er parallel die Daten über USB an den PC liefert (ok, fiktives Beispiel). Grüße Andreas
Future schrieb: > Nach deiner Argumentation müssten alle den Führerschein auf so einem > Auto machen: > http://www.deutsches-museum.de/typo3temp/pics/79179e0e95.jpg > ;-))) Gutes Beispiel. Aber: Und wenn Du mal in Unfallstatistiken schauen würdest, würd Dir sicher auffallen, dass ein großer Anteil der Unfallverursacher Fahranfänger sind^^ Es gibt aber auch kritischere Gebiete als Autos. Wieviel Flugstunden/Landungen must Du mit PPL nachweisen, bevor Du Personen mitnehmen darfst ? Gute Nacht :-) Andreas
Andreas H. schrieb: > Gutes Beispiel. Aber: > > Und wenn Du mal in Unfallstatistiken schauen würdest, würd Dir sicher > auffallen, dass ein großer Anteil der Unfallverursacher Fahranfänger > sind^^ Wo besteht denn jetzt hier der Zusammenhang??? Liegt die Unfallhäufigkeit an dem Fahrschulfahrzeug??? Andreas H. schrieb: > Wieviel Flugstunden/Landungen must Du mit PPL nachweisen, bevor Du > Personen mitnehmen darfst ? Mit welchem Gefährt lernt man heute? Mit so einem? http://thumbs.dreamstime.com/z/altes-flugzeug-159492.jpg
Future schrieb: > Andreas H. schrieb: >> Gutes Beispiel. Aber: >> >> Und wenn Du mal in Unfallstatistiken schauen würdest, würd Dir sicher >> auffallen, dass ein großer Anteil der Unfallverursacher Fahranfänger >> sind^^ > > Wo besteht denn jetzt hier der Zusammenhang??? > Liegt die Unfallhäufigkeit an dem Fahrschulfahrzeug??? Nein. Anscheinend an der fehlenden Routine der Fahranfänger. > > Andreas H. schrieb: >> Wieviel Flugstunden/Landungen must Du mit PPL nachweisen, bevor Du >> Personen mitnehmen darfst ? > > Mit welchem Gefährt lernt man heute? Mit so einem? > http://thumbs.dreamstime.com/z/altes-flugzeug-159492.jpg Du musst Flugstunden/Landungen (also Flugerfahrung) nachweisen. Darum geht es^^ Und PPL macht man auf einmotorigen Maschinen. Obwohl, wenn es nach Dir ginge, dann ware sicher auch eine F/A-18 möglich (omg). Gute Nacht Andreas
Andreas H. schrieb: > Nein. Anscheinend an der fehlenden Routine der Fahranfänger. Ok, wenn es nicht am Golf oder 5er BMW liegt sind wir uns einig: 32Bit sind genauso gut für Anfänger geeignet wie ein 8Bitter. Andreas H. schrieb: > Du musst Flugstunden/Landungen (also Flugerfahrung) nachweisen. Darum > geht es^^ Genau, egal ob Auto, Flugzeug oder µC. Heute lernt man auf aktueller Technik. Und das darf der Derby (AVR), der Golf (MSP430) oder auch der Phäton (ARM) sein. ;-)))
Future schrieb: > Genau, egal ob Auto, Flugzeug oder µC. Heute lernt man auf aktueller > Technik. Du begreifst es nicht. Man wählt den uP nach der zu lösenden Aufgabe aus. Und die sind bei Anfängern im allgemeinen "Anfängergerecht". Der Anfänger weiss ja u.U noch garnicht, welche Teile des Prozessors erst mal für ihn, bei einer gegebenen Aufgae, relevant sind. Und schicke LIBs bei den Kits sind toll. Aber erst wenn man weiss, was sie bewirken. Sonst fängt man jedes mal wieder bei 0 an. Simples Beispiel: Du machst auf einem 8-Bit AVR einen Pin zum Ausgang, indem Du eine 0 in das DDRx Register schreibst. Beim PIC must Du dazu eine 1 in das TRIS Register schreiben. Da siehst Du als Anfänger aber die Register noch. Beim Arduino wird das AFAIK schon durch die LIBs gekapselt. Wo ist da der Lerneffekt ? Wieviel Overhead produziert die LIB an dieser Stelle ? Wo hast Du also noch Potential, um im Zweifelsfall noch etwas Leistung rauszukitzeln ? (Wir sind uns sicher einig das Festplatten immer zu klein und Prozessoren immer zu langsam sind. Bei letzteren wahlweise auch zu wenig RAM/FLASH/EE.) Versteh mich nicht falsch. Ich halte SW Unterstützung für extrem nützlich. Aber nur wenn man weiss, was da passiert. Aber genau DAS fehlt den Anfängern dann. Wir reden hier ja nicht davon eine konkrete Aufgabe zu lösen. Der TO will sich ja allgemein in die Embedded Programmierung einarbeiten. Und da sollte er dann schon mal ein Gefühl für die Hardware bekommen. Bei Deinem Autovergleich lernt ja auch kein Fahranfänger Rallys zu fahren. Sondern nur sicher von A nach B zu kommen. Solange er nicht weiss, wofür er da die drei Pedale hat, muss man ihn nicht dadurch verunsichern, dass man ihm zeigt, wie man auf dem Nürburgring Kurven bei 290Km/h anfährt. Das macht er im schlimmsten Fall nämlich mal nach. Grüße Andreas
Stefan Tully schrieb: > Hallo zusammen, > ich bin absoluter Neueinsteiger in die Welt der Elektronik und > Mikrocontroller Programmierung. Ein bisschen Programmierung habe ich in Auch einen Führerschein darf man in der Regel erst ab 18 machen. Warum wohl? Weil man bis dahin schon Verkehrsteilnehmer war und eine gewisse Lebenserfahrung gesammelt hat. Man braucht dann nur noch ein paar Bedienelemente am Auto in der richtigen Reihenfolge zu betätigen und einige Regeln zu beachten. Aber wehe, wenn so ein Ding nicht mehr tut. Mir würde es bei einem Fahrrad leichter fallen den Fehler zu finden bzw. das Ding wieder zum Laufen zu bringen bevor man die Werkstatt aufsucht. Eine Entscheidungshilfe zur Wahl eines µC für einen Anfänger könnte die Seitenanzahl des zugehörigen Datenblattes sein. Je weniger Seiten, desto schneller könnte man sich zurechtfinden. Vorher sollte man aber schon Bergriffe wie Strom und Spannung richtig gebrauchen lernen und wissen warum Widerstand nicht mit ie geschrieben wird.
basics schrieb: > Eine Entscheidungshilfe zur Wahl eines µC für einen Anfänger könnte die > Seitenanzahl des zugehörigen Datenblattes sein. Je weniger Seiten, desto > schneller könnte man sich zurechtfinden. Würde ich so nicht unterschreiben. Es gibt durchaus bracubare Datenblätter die locker einige hundert Seiten umfassen. Ansonsten triffts Dein Vergleich Fahrrad vs. Auto schon ziemlich gut :-) Grüße Andreas
Andreas H. schrieb: > Simples Beispiel: Du machst auf einem 8-Bit AVR einen Pin zum Ausgang, > indem Du eine 0 in das DDRx Register schreibst. Beim PIC must Du dazu > eine 1 in das TRIS Register schreiben. Beim STM32 musst du halt noch den Clock für die Peripherie einschalten, das war's. Ich habe bisher immer "Bare-Metal" gearbeitet, der Code ist im Endeffekt nicht viel länger als bei einem AVR. Das Problem ist eher die Beschreibung, weil man erst einmal durchblicken muss, was man nicht braucht. Vielleicht fehlt es einfach nur an einem vernünftigen "Bare-Metal" Tutorial für STM32. Oder gibt es das evtl. sogar schon? Alternativ wäre immer noch der SAMD20 einen Blick wert, die Peripherie sieht nicht sehr komplex aus.
Antimedial schrieb: > > Alternativ wäre immer noch der SAMD20 einen Blick wert, die Peripherie > sieht nicht sehr komplex aus. Sonder Spezialtypen empfehlen??? Da wird er wohl nie viel Hilfe hier erhalten.
Markus Müller schrieb: > Sonder Spezialtypen empfehlen??? > Da wird er wohl nie viel Hilfe hier erhalten. Was ist daran ein "Sonderspezialtyp"? Das Ding ist noch relativ neu, wird aber wahrscheinlich den 8-Bit AVR bei Atmel über kurz oder lang ersetzen.
Ich habe von dem noch nie was hier im Forum gelesen. Somit sollte der Anfänger den nicht nehmen. Besser AVR oder STM32, er muss sich nun selbst für einen entscheidenden.
Erst einmal halte ich es sowieso für Unsinn, nur genau eine Plattform zu wählen und so zu tun, als würde man dann für immer dort bleiben. Es ist viel besser, sich schon ein paar verschiedene anzuschauen, um auch mal ein Gefühl für die Unterschiede zu bekommen. Es schadet überhaupt nichts, sich mal das Datenblatt eines D20 herzunehmen und mit einem AVR zu vergleichen. Das kann man auch als Anfänger mal tun, wenn man sich mal ein paar Tage mit µC beschäftigt hat und vielleicht das ein oder andere Beispiel mal ausprobiert hat. Und dass du in dem Forum so etwas nicht liest ist nicht verwunderlich, vermutlich hat sich der D20 bei Hobbybastlern noch nicht so sehr herumgesprochen.
Das Datenblatt laden reicht nicht. Man muss auch suchen wo man den kaufen kann! Wenn es den nur schwer zu kaufen gibt, dann lieber gleich vergessen.
Doch, es reicht schon einmal, das Datenblatt anzuschauen um festzustellen "Ach ja, der ist dem AVR doch recht ähnlich". Oder auch nicht. Dann kann man immer noch schauen, wo man ein Entwicklungskit bekommt und dabei feststellen, dass man den durchaus bekommen kann.
Antimedial schrieb: > Doch, es reicht schon einmal, das Datenblatt anzuschauen um > festzustellen "Ach ja, der ist dem AVR doch recht ähnlich". Oder auch > nicht. Dann kann man immer noch schauen, wo man ein Entwicklungskit > bekommt und dabei feststellen, dass man den durchaus bekommen kann. Genau das dürfte des "absoluter Neueinsteiger" höchstes Intresse sein. Wie Bits in welchen Registern setzen und warum überhaupt wird dann im Forum diskutiert. Bin mal gespannt, wie dann die Antworten auf solche Fragen ausfallen. Da dürfen dann die Moderatoren wieder ran mit Antworten löschen bzw sachgerechte Antworten geben. Weis denn hier kaum noch jemand, wie er mit welchen Voraussetzungen angefangen hat? Upgraden kann man ja immer noch und einem Hobbybastler fällt das ja leicht, wenn es nicht um Stückzahlen geht.
Meine Meinung: Steig mit einem Arduino System ein. Das ist sehr sehr übersichtlich. Du hast schnelle Erfolge und bekommst viel Hilfe. Später kannst Du dann zu nem STM32 umsteigen. Die Peripherie ist wie schon beschrieben etwas komplexer und es sieht ein bisschen unübersichtlicher aus. Mehr aber auch nicht. STM32 hat aber auch einen großen Vorteil gegenüber Arduino und AVR: Du bekommst mit dem ST32Discovery bereits für 20Euro ein gutes System mit Debugger! Wenn also etwas nicht so läuft, wie es Du Dir vorgstellt hast, kannst Du bis zu einer bestimmten Stelle laufen und Dir die Inhalte aller Variablen ansehen. Das hilft vielmals.
Im für Einsteiger doch recht brauchbaren AVR-GCC-Tutorial arbeitet man doch auf Registerebene. Ich sehe da kein Problem, wenn ein bisschen technisches Verständnis und Vorkenntnisse in Binarzählen, Programmieren und so weiter vorhanden sind.
d&g schrieb: > Meine Meinung: > Steig mit einem Arduino System ein. Das ist sehr sehr übersichtlich. Du > hast schnelle Erfolge und bekommst viel Hilfe. > > Später kannst Du dann zu nem STM32 umsteigen. Die Peripherie ist wie > schon beschrieben etwas komplexer und es sieht ein bisschen > unübersichtlicher aus. Mehr aber auch nicht. > > STM32 hat aber auch einen großen Vorteil gegenüber Arduino und AVR: > Du bekommst mit dem ST32Discovery bereits für 20Euro ein gutes System > mit Debugger! Wenn also etwas nicht so läuft, wie es Du Dir vorgstellt > hast, kannst Du bis zu einer bestimmten Stelle laufen und Dir die > Inhalte aller Variablen ansehen. Das hilft vielmals Und warum dann nicht direkt mit einem Cortex einsteigen ? Arduino macht gar keinen Sinn mehr . Wenn das Teil überhaupt jemals Sinn gemacht hat. Und ja ein Cortex hat mehr Peripherie Module. Aber was soll es, man muss nur die Einschalten die man für die jeweilige Anwendung brauch, der Rest ist nur vorhanden, muss nicht konfiguriert werden und stört nicht.
>Und warum dann nicht direkt mit einem Cortex einsteigen ? Weil ich schon 3 Schülerprojekte (10. Klasse hatte). Denne hab ich einen Arduino hingelegt, gezeigt wie man ne LED ansteuert, die Arduino Webseite gezeigt und sie haben dann innerhalb den nächsten paar Tagen fast selbständig jedesmal tolle Projekte hinbekommen. Bin überascht, wie gut und ohne viel Hilfe die damit klar kamen. Ich selbst arbeite mit STM32. Würde mich als "erfahren" einschätzen, habe aber schon viel Blut geschwitzte, um das unter Linux zum Laufen zu bekommen. Klar CooCox unter Windows geht einfach.
>Kann man bei einem Arduino nicht debuggen?
Glab nicht, oder ? Gut - hat ne einfache serielle Schnittstelle, die oft
hilft.
>Und warum dann nicht direkt mit einem Cortex einsteigen ? Oder um es so zu sagen: Wenn Jemand einem Anfänger eine STM32 Umgebung einrichtet und die ersten Schritte zeigt geht es auch.
d&g schrieb: >>Kann man bei einem Arduino nicht debuggen? > Glab nicht, oder ? Gut - hat ne einfache serielle Schnittstelle, die oft > hilft. Dann werde ich wohl NIE NIE NIE wieder einem Anfänger einen Arduino empfehlen. Einen AVR kann ich nur empfehlen, wenn man sich auch gleich dazu einen Debugger kauft, damit man durch den Prozessor durch steppen kann und sieht wie der rechnet. Allerdings ist der kleine AVR etwas begrenzt was die Breakpoints angeht. Ein STM32 (alle mit Cotex-Mx Core) haben 6 Breakpoints und damit lässt sich schon ganz gut debuggen. Ich hatte zu Anfang (vor 20 Jahren) nur einen Programmer (EPROM) und ich weiß wie schwer es das war. Nur mit Debugger kann man die Prozessor-Register und die Register der Pheriperie lesen (beim AVR und STM32 gleichermaßen).
d&g schrieb: > Glab nicht, oder ? Gut - hat ne einfache serielle Schnittstelle, die oft > hilft. Mit der seriellen Schnittstelle zu debuggen ist wie mit einem Küchenmesser eine Hirn-OP durchführen zu wollen. Nein, ernsthaft, die serielle Schnittstelle kann man sehr gut als Hilfe zum Tracen verwenden, aber das echte Debugging ist trotzdem nicht ersetzbar.
Andreas H. schrieb: > Nachteilig empfinde ich bei den 32-Bit CPUs, dass sie extreme viel > (sinnvolle) Features haben, die einen Anfänger extreme verwirren können. Wasn das für ein immer wieder angebrachtes Nullargument? Man nutzt nur die Features die man braucht, dann verwirren die mich auch nicht. Deshalb kann man auch gleich mit einem 32-Biter anfangen.
Antimedial schrieb: > Mit der seriellen Schnittstelle zu debuggen ist wie mit einem > Küchenmesser eine Hirn-OP durchführen zu wollen. Für einen Arduino reicht das. Entsprechende Textmeldungen ausgeben fertig, das ist nix anderes als Breakpoints, nur dass du halt aufs Konsolenfenster schauen musst. Einen Debugger in Hardware für MCs habe ich bis heute nie gebraucht, egal welchen Prozessor ich verwendet habe. Bei Software die auf PCs laufen soll brauche ich den Debugger in einer IDE auch selten, ich denke lieber erst mal nach dann komme ich meistens ohne Debugger darauf. Wenn ich Kollegen mit dem Debugger rumhantieren sehe hat das immer was von Trial&Error-Methodik.
Schwen Gel schrieb: > Wasn das für ein immer wieder angebrachtes Nullargument? Man nutzt nur > die Features die man braucht, dann verwirren die mich auch nicht. > Deshalb kann man auch gleich mit einem 32-Biter anfangen. Leider verwirren sie doch, wenn die Beschreibung nicht ausreichend kapselt. Man muss sich teilweise schon durch zig Seiten wühlen und dann erst einmal wissen, was man braucht und was nicht. Beim STM32 ist das z.B. bei der PWM der Fall. Wenn sie mal funktioniert ist es dann aber nicht schwerer als beim AVR. Deshalb fände ich ein gutes Tutorial, das gleich die nötige Kapselung erledigt, sehr hilfreich. Schwen Gel schrieb: > Für einen Arduino reicht das. Entsprechende Textmeldungen ausgeben > fertig, das ist nix anderes als Breakpoints, nur dass du halt aufs > Konsolenfenster schauen musst. Ein Breakpoint ist viel mächtiger als eine simple Textmeldung. Schwen Gel schrieb: > Einen Debugger in Hardware für MCs habe ich bis heute nie gebraucht, > egal welchen Prozessor ich verwendet habe. Ja, das ist ein typisches Argument "was der Bauer nicht kennt, frisst er nicht". Wenn du mal die Vorteile des Debuggens kennengelernt hast, wirst du plötzlich merken, wie ineffektiv du die ganze Zeit gearbeitet hast. Schwen Gel schrieb: > Wenn > ich Kollegen mit dem Debugger rumhantieren sehe hat das immer was von > Trial&Error-Methodik. Ich bin großer Fan von Trial&Error-Vorgehen (zumindest ab einer gewissen Ebene), weil es viel effektiver ist als ewiges Stöchern im Dunkeln.
> Ein Breakpoint ist viel mächtiger als eine simple Textmeldung. Manchmal. Ich kann mit einem printf() meist mehr anfangen. > Schwen Gel schrieb: >> Einen Debugger in Hardware für MCs habe ich bis heute nie gebraucht, >> egal welchen Prozessor ich verwendet habe. > > Ja, das ist ein typisches Argument "was der Bauer nicht kennt, frisst er > nicht". Wenn du mal die Vorteile des Debuggens kennengelernt hast, wirst > du plötzlich merken, wie ineffektiv du die ganze Zeit gearbeitet hast. Ich habe hier seit 2010 einen J-Link und drei oder vier Discovery Boards und nutze die Dinger praktisch nur zum Flashen. Dabei müsste ich unter Crossworks nur die F10 Taste drücken um den Debugger zu starten. Ich brauche keinen Debugger um meinen Code zu lesen und zu verstehen. Debug Sessions haben mich auch schon eine Menge Zeit gekostet. Für AVR habe ich sowohl einen AVRispMkII als auch einen Dragon. Jetzt rate was ich benutze. Jeder hat seine eigne Arbeitsweise. Manchmal ist etwas besser oder schlechter. Oft aber einfach nur anders.
Antimedial schrieb: > Das Ding ist noch relativ neu, > wird aber wahrscheinlich den 8-Bit AVR bei Atmel über kurz oder lang > ersetzen. Kann ich mir kaum vorstellen. Ein gewisser Charme der AVRs liegt ja auch im Package. Die gibts schon mit acht Pins (PICs auch). Da kannst Du schnell mal einen "Bugfix", bzw. eine Erweiterung, auf ein Board basteln. Den SAMD20 gibt minimal mit 32 Pins im TQFP Gehäuse. Grüße Andreas
Schwen Gel schrieb: > Wasn das für ein immer wieder angebrachtes Nullargument? Man nutzt nur > die Features die man braucht, dann verwirren die mich auch nicht. > Deshalb kann man auch gleich mit einem 32-Biter anfangen. Es haben schon haufenweise Leute gezeigt, dass sie sich schon auf 8-Bit uPs prima aufrauchen konnten (denk mal an das bekannte AVR Fuse Problem). Die Probleme fangen ja immer dann an, wenn der uP etwas anderes macht, als Du erwartet hattest. Und wie bist Du Dir jetzt sicher, wo der Fehler nicht liegt ? Und da man ja evtl. auch mal die Hardware auf einem eigenen Board einsetzen will, ist hier auch für die Anfänger ein DIL Gehäuse etwas praktischer. Antimedial schrieb: > Deshalb fände ich ein gutes Tutorial, das gleich die nötige Kapselung > erledigt, sehr hilfreich. Wird dann aber sehr umfangreich, da jeder Hersteller eigene Peripherie an den Core ranbastelt. Da ist der Einstieg beim AVR etwas einfacher :-D Grüße Andreas
Stefan schrieb: > Manchmal. Ich kann mit einem printf() meist mehr anfangen. Dann hast du wohl noch nicht begriffen, was man mit einem Debugger so alles anstellen kann. Du hast auf jeden Fall sehr viel Spaß, wenn du dir den kompletten Registersatz einer Peripherie mit einem simplen printf rausholen willst. Stefan schrieb: > Jeder hat seine eigne Arbeitsweise. Manchmal ist etwas besser oder > schlechter. Oft aber einfach nur anders. Manche Leute können mit ihren Werkzeugen auch einfach nicht umgehen. Wer die Vorteile des Debuggers nicht nutzen kann, arbeitet ineffektiv. Andreas H. schrieb: > Ein gewisser Charme der AVRs liegt ja auch im Package. Die gibts schon > mit acht Pins (PICs auch). Da kannst Du schnell mal einen "Bugfix", bzw. > eine Erweiterung, auf ein Board basteln. Siehe LPC800, es geht also schon. Und Atmel wird nachziehen, wenn Bedarf besteht. Den SAMD20 gibt es erst seit ein paar Monaten, und dafür ist das Portfolio schon sehr umfangreich. Andreas H. schrieb: > Wird dann aber sehr umfangreich, da jeder Hersteller eigene Peripherie > an den Core ranbastelt. > Da ist der Einstieg beim AVR etwas einfacher :-D Was ist das für ein Argument? Das AVR-Tutorial hat doch auch nicht den Anspruch, gleichzeitig 8051er und PIC zu erschlagen.
Schwen Gel schrieb: > Entsprechende Textmeldungen ausgeben > fertig, das ist nix anderes als Breakpoints, nur dass du halt aufs > Konsolenfenster schauen musst. Du verlierst den Kontext des Programms. Beim BP bleibt der Prozessor an der Stelle stehen und Du kannst Dir die Variablen anschauen. Bei Fehlern, die alle 1E8 cycles mal sporadisch auftauchen schon ganz praktisch. Bei Textausgabe via UART veränderst Du ausserdem noch das Timing der Programmausfürhung. > Einen Debugger in Hardware für MCs habe ich bis heute nie gebraucht, > egal welchen Prozessor ich verwendet habe. <irony> Naja, "Hello world\n" kriegt man auch so hin. </irony> Im Ernst: Solange es geht, nehme ich auch Textausgabe über eine UART ... falls noch eine frei ist (meist nicht). Grüße Andreas
Entschuldigt, liebe Leute, aber ich habe so das Gefühl, dass der arme Stefan auf Grund Eurer hitzigen Diskussionen jetzt noch unschlüssiger sein könnte. ;-) Meine Meinung ist die, dass für einen Anfänger so ein Entwicklungsboard von Pollin ausreicht. Und am besten das AddOn-Board gleich dazukaufen. Kostet nicht die Welt und man hat die Wahl unter etlichen AVRs, vom kleinen Attiny13 bis zum Atmega32. Und alles im DIL-Package. Für den Atmega32 würde ich einen Nullkraft-Sockel empfehlen. Tja, und ein "mySmartUSB light"- Programmiergerät kann sich wohl jeder leisten und es ist bestimmt nicht schlecht. Programmiersprache? Ich finde, dass man mit C mit und ohne ++ auf jeden Fall am meisten lernt, von Assembler abgesehen. Warum? Weil man das Innenleben der Controller damit am besten kennenlernt. Die "Kasteneinteilung" unseres Meister-Schimpfers halte ich aber nicht für gerecht. Ich finde das intolerant. BASCOM ist nicht so schlecht, wie es hier immer dargestellt wird und Arduino ist doch für Einsteiger auch eine feine Sache. Bei beiden steht man halt irgendwann mal an und das ist schon bei der Timer- und Interrupt-Programmierung der Fall. Und die Realisierung seines Projektes kann ganz prima mit dem sehr günstigen Sprint Layout-Programm erfolgen: http://www.abacom-online.de/html/sprint-layout.html Ich persönlich brauche für meine privaten Zwecke keine Multilayer über EAGLE. (Obwohl das Programm sakrisch gut ist)
Antimedial schrieb: >> Manchmal. Ich kann mit einem printf() meist mehr anfangen. > > Dann hast du wohl noch nicht begriffen, was man mit einem Debugger so > alles anstellen kann. Nichts gegen Kritik, doch ich glaube kaum dass du nach ein paar Sätzen beurteilen kannst was ich begriffen habe und was nicht. Ich habe früher bei PC Programmen viel mit Debuggern gearbeitet. Mache ich heute auch nicht mehr. Wenn du einen Debugger brauchst um effektiv zu arbeiten dann benutze ihn doch. Dafür sind sie da. Doch unterstelle bitte Anderen keine Ineffizienz wenn sie anders arbeiten/denken. > Du hast auf jeden Fall sehr viel Spaß, wenn du dir den kompletten > Registersatz einer Peripherie mit einem simplen printf rausholen willst. Nur gut dass mich das auch gar nicht interesssiert. Was soll da drinstehen? Ich wüßte jetzt jedenfalls nicht dass ich in den vergangen Jahren Probleme gehabt hätte bei denen ich auf Registerebene runter musste.
Stefan schrieb: > Nichts gegen Kritik, doch ich glaube kaum dass du nach ein paar Sätzen > beurteilen kannst was ich begriffen habe und was nicht. > Ich habe früher bei PC Programmen viel mit Debuggern gearbeitet. Mache > ich heute auch nicht mehr. > Wenn du einen Debugger brauchst um effektiv zu arbeiten dann benutze ihn > doch. Dafür sind sie da. Doch unterstelle bitte Anderen keine > Ineffizienz wenn sie anders arbeiten/denken. Sagen wir es mal so, ich habe solche Argumentationen schon so oft gehört, das sich weiß, worauf es hinaus läuft. Stefan schrieb: > Nur gut dass mich das auch gar nicht interesssiert. Was soll da > drinstehen? > Ich wüßte jetzt jedenfalls nicht dass ich in den vergangen Jahren > Probleme gehabt hätte bei denen ich auf Registerebene runter musste. Gut, du arbeitest vielleicht auf einer anderen Ebene. Mit dem Arduinokram muss man das vielleicht nicht machen. Das wäre mir aber zu ineffizient.
Ihr schweift immer mehr von der eigentlichen Fragestellung ab! ;-) Da will jemand in die µC-Programmierung einsteigen, und ihr kommt mit 32 Bit daher! ;-) Für einen Anfänger! Findet ihr nicht, dass das etwas übertrieben ist?
Zum Beispiel finde ich " Bit-band mapping" beim 32 bit Mikrokontroler interessant. Der Preis des Disco Boards günstig. Hochwertiges USB Kabel dazu. Warum mit 8 Bit anfangen?
Blende22 schrieb: > Ihr schweift immer mehr von der eigentlichen Fragestellung ab! ;-) > Da will jemand in die µC-Programmierung einsteigen, und ihr kommt mit 32 > Bit daher! ;-) Für einen Anfänger! Findet ihr nicht, dass das etwas > übertrieben ist? Wurde oben schon genannt, es ist egal welcher Hersteller und wenn's 512bit sind sind's halt 512bit. Es kommt darauf an was er machen will und für einfache Basteleien reichen 8bit i.d.R. mehr als aus. Wenn er dann mal DDS in HiFi machen will muß er halt auf größere "Geschütze" umstellen oder einfach einen DDS Chip an den 8bitter hängen :-P Diese gesamte sinnlose Diskussion wird ja schon durch die Bewertungen als eben das gekennzeichnet. Da ich allerdings Aversionen gegen Excel-Tabellen habe weiß ich ja nicht was er sich so zulegen will, gehe aber mal davon aus das er damit LEDs blinken lassen kann und Nachbars Fernseher halt mal aus ist wenn zu laut :-P Wir werden ja sehen ob hier vom TO Fragen über AVR auftauchen oder MIPS ;-)
Blende22 schrieb: > Ihr schweift immer mehr von der eigentlichen Fragestellung ab! ;-) Du hast völlig recht. Ein kurzer OT Kommentar sei mir aber bitte noch gestattet: <offtopic> Stefan schrieb: > Ich habe früher bei PC Programmen viel mit Debuggern gearbeitet. Mache > ich heute auch nicht mehr. Ich gebe zu, das ich mich auch gerne um den Debugger "drücke". Aber einen entscheidenden Vorteil hat das Ding ja schon: Wenn Du bei Embedded CPUs Hardware (!) Breakpoints hast, dann beeinflussen die die normale Programmausführung nicht (SW Breakpoints verzweigen ja in eine SW Debugroutine). Der Debugger arbeitet dann (meist via JTAG o.ä.) "ausserhalb der CPU cycles". Damit kann man dann auch das Environment betrachten, was bei einem Softwaredebugger schon allein durch das notwendige sichern der Register zerstört werden kann. </offtopic> Grüße Andreas
Antimedial schrieb: > Ich bin großer Fan von Trial&Error-Vorgehen (zumindest ab einer gewissen > Ebene), weil es viel effektiver ist als ewiges Stöchern im Dunkeln. T&E IST stochern im Dunkeln par excellence!
Schwen Gel schrieb: > T&E IST stochern im Dunkeln par excellence! Nein, eben nicht! Es ist genau genommen die Grundlage der agilen Entwicklung. Schnell kleine Änderungen durchführen und deren Auswirkungen beobachten. Bei einem "Irrtum" (nicht Fehler!) geht man wieder einen Schritt zurück oder geht nochmal einen Schritt weiter. Das ganze Vorgehen ist viel systematischer als diese üble "Top-Down"-Entwicklung, in der man monatelange erst einmal eine Architektur definiert, die man in der Praxis nie umsetzen kann und man dann in ewig langen Releasezyklen mit enormem Testaufwand das ganze komplexe Gebilde (meist vergeblich) versucht in Griff zu bekommen. Bei den meisten zurückgebliebenen Entwicklern sind Ideen aus der agilen Entwicklung natürlich reinste Ketzerei, aber denen ist halt nicht mehr zu helfen. Blende22 schrieb: > Da will jemand in die µC-Programmierung einsteigen, und ihr kommt mit 32 > Bit daher! ;-) Für einen Anfänger! Findet ihr nicht, dass das etwas > übertrieben ist? Nein, wieso sollte es denn übertrieben sein? 32 Bit sind viel einfacher zu handhaben.
Antimedial schrieb: > 32 Bit sind viel einfacher zu handhaben. Genau. Praktisches Beispiel hier: Beitrag "Bytevergleich STM32 erfolglos" <offtopic> lol </offtopic> Sorry, der musste jetzt sein ;-) Grüße Andreas
Antimedial schrieb: > Das ganze Vorgehen ist viel systematischer als diese üble > "Top-Down"-Entwicklung, in der man monatelange erst einmal eine > Architektur definiert, die man in der Praxis nie umsetzen kann und man > dann in ewig langen Releasezyklen mit enormem Testaufwand das ganze > komplexe Gebilde (meist vergeblich) versucht in Griff zu bekommen. > > Bei den meisten zurückgebliebenen Entwicklern sind Ideen aus der agilen > Entwicklung natürlich reinste Ketzerei, aber denen ist halt nicht mehr > zu helfen. Ist dir irgendwie langweilig? Nein? Dann begründe diese Vorwürfe bitte!
Mein kurzes Statement: Besser mit einem 8/16-Bitter anfangen, da ist alles etwas einfacher, eingeschränkter und simpler. Das ist für den Anfang keine schlechte Sache, im Gegenteil. Welcher MCU es nun ist, das ist im Endeffekt eigentlich egal, aber verbreitete MCU-Reihen (AVR, PIC, MCS-51) sind natürlich von Vorteil. Guter Tool-Support ist ebenfalls wichtig, das sollte man nicht unterschätzen.
Andreas H. schrieb: > Du begreifst es nicht. Da wäre ich mir aber nicht so sicher. Du schreibst 8 Bit hast aber ganz konkret AVR im Kopf. Du schreibst 32 Bit und denkst nur an ARM. Mach dich davon frei und du hast es begriffen: die Bitbreite spielt keine Rolle. Andreas H. schrieb: > Versteh mich nicht falsch. Ich halte SW Unterstützung für extrem > nützlich. Aber nur wenn man weiss, was da passiert. Aber genau DAS fehlt > den Anfängern dann. Wie machst du das bei Oberflächenprogrammierung? Kennst du jede Zeile im Linux Kenrnel? Andreas H. schrieb: > Solange er nicht weiss, wofür er da die drei Pedale hat, muss man ihn > nicht dadurch verunsichern, dass man ihm zeigt, wie man auf dem > Nürburgring Kurven bei 290Km/h anfährt. Das macht er im schlimmsten Fall > nämlich mal nach. Wenn er heute auf den Verkehr losgelassen wird, sollte er auf der Autobahn 200km/h fahren können. Vor 50 Jahren reichten 120km/h. ;-)
Future schrieb: > Da wäre ich mir aber nicht so sicher. Du schreibst 8 Bit hast aber ganz > konkret AVR im Kopf. >Du schreibst 32 Bit und denkst nur an ARM. Mach > dich davon frei und du hast es begriffen: die Bitbreite spielt keine > Rolle. Wie kommst Du denn auf diesen Schwachsinn ? Ich hab mich hier nur hauptsächlich auf diese beiden Typen bezogen, weil dass Thema des Threads ja eigentlich in die Frage abdriftete, was für einen Anfanger besser ist. Ansonsten wird alles programmiert was passt - die Dinger sind ja kein Selbstzweck. Für den Luxus einer "Prozessorliebe" bin ich zu faul. Für die permanente Suche nach dem "Hype-uP of the year" allerdings auch. Wenn Du im ASIC Bereich arbeitest, dann klären sich da viele Mythen ziemlich ab ;-) Grüße Andreas
Future schrieb: > Da wäre ich mir aber nicht so sicher. Du schreibst 8 Bit hast aber ganz > konkret AVR im Kopf. Du schreibst 32 Bit und denkst nur an ARM. Mach > dich davon frei und du hast es begriffen: die Bitbreite spielt keine > Rolle. Das ist in der Theorie richtig, aber bei MCUs geht mit größerer Bitbreite eine allgemein größere Komplexität einher, auf mehreren Ebenen.
greg schrieb: > Das ist in der Theorie richtig, aber bei MCUs geht mit größerer > Bitbreite eine allgemein größere Komplexität einher, auf mehreren > Ebenen. Bitte vergleiche einen 8 Bit AVR mit einem 16 Bit MSP430. Gilt deine Annahme da auch?
Stefan schrieb: > Ist dir irgendwie langweilig? Nein? Dann begründe diese Vorwürfe bitte! Das sind keine Vorwürfe, das war eine Schilderung meiner Erfahrungen in der Entwicklung, und außerdem auch die Meinung vieler Verfechter von agiler Entwicklung (insbesondere dem Devops-Ansatz). greg schrieb: > Das ist in der Theorie richtig, aber bei MCUs geht mit größerer > Bitbreite eine allgemein größere Komplexität einher, auf mehreren > Ebenen. Und Komplexität kann man auf vielen Ebenen wieder einholen. Die CPU eines Raspberry Pi ist auch unheimlich komplex, trotzdem kann man einem Anfänger innerhalb weniger Stunden erste Schritte beibringen. Ein PC ist auch unheimlich komplex (übrigens 64 Bit heutzutage meistens), trotzdem fangen die meisten Menschen dort an, weil sie es leichter empfinden als die AVR-Programmierung.
Future schrieb: > greg schrieb: >> Das ist in der Theorie richtig, aber bei MCUs geht mit größerer >> Bitbreite eine allgemein größere Komplexität einher, auf mehreren >> Ebenen. > > Bitte vergleiche einen 8 Bit AVR mit einem 16 Bit MSP430. Gilt deine > Annahme da auch? Naja, die Peripherie ist etwas umfangreicher und schwieriger zu nutzen als beim typischen 8-Bitter, aber der größte Unterschied ist meistens schon beim Schritt zu 32 Bit auszumachen. Antimedial schrieb: > Stefan schrieb: >> Ist dir irgendwie langweilig? Nein? Dann begründe diese Vorwürfe bitte! > > Das sind keine Vorwürfe, das war eine Schilderung meiner Erfahrungen in > der Entwicklung, und außerdem auch die Meinung vieler Verfechter von > agiler Entwicklung (insbesondere dem Devops-Ansatz). > > greg schrieb: >> Das ist in der Theorie richtig, aber bei MCUs geht mit größerer >> Bitbreite eine allgemein größere Komplexität einher, auf mehreren >> Ebenen. > > Und Komplexität kann man auf vielen Ebenen wieder einholen. Die CPU > eines Raspberry Pi ist auch unheimlich komplex, trotzdem kann man einem > Anfänger innerhalb weniger Stunden erste Schritte beibringen. Ein Raspberry Pi ist auch wieder so komplex und bietet so viele Ressourcen, dass man auf einer sehr hohen Abstraktionsebene programmieren kann, wie auf einem PC. Bei einem kleinen 32 Bit MCU geht das noch nicht. Da schreibt man direkt auf der Hardware operierendes C wie auf einem 8/16-Bitter, aber andererseits hat man es mit einem deutlich komplexeren System zu tun. Das Raspberry Pi hat dazu noch exzellenten Softwaresupport, das bekommt man in seltensten Fällen von den MCU-Herstellern. Z.B. die STM32 Standard Peripheral Library wird hier ja regelmäßig niedergemacht. Es ist das gleiche Problem wie bei vielen ARM Development Boards: die Hardwarehersteller verstehen nix von Software und es gibt nur ein lieblos hingerotztes BSP mit seltenen (oder gar keinen) Updates und Bugfixes. Vielleicht gibt es ja tatsächlich MCUs mit > 16 Bit Bitbreite und geringer Gesamtkomplexität, aber so etwas habe ich noch nicht gesehen.
greg schrieb: >> Bitte vergleiche einen 8 Bit AVR mit einem 16 Bit MSP430. Gilt deine >> Annahme da auch? > > Naja, die Peripherie ist etwas umfangreicher und schwieriger zu nutzen > als beim typischen 8-Bitter, Du hast auf beiden Controllern vergleichbare Aufgaben gelöst? Wenn ja, wundert mich deine Antwort. Die meisten Entwickler sehen es genau gegenteilig: Der MSP430 (16 Bit) ist einfacher zu nutzen als der AVR (8 Bit).
greg schrieb: > Das ist in der Theorie richtig, aber bei MCUs geht mit größerer > Bitbreite eine allgemein größere Komplexität einher, auf mehreren > Ebenen. Absolute Aussagen in einem so derart vielfältigen Bereich wie dem der auch dem Markt erhältlichen µC Varianten sind immer extrem Problematisch. Aber im allgemeinen gilt das oben gesagte schon - Ausnahmen können die Regel aber durchaus auch bestätigen... Antimedial schrieb: > Ein PC ist auch unheimlich komplex (übrigens 64 Bit heutzutage meistens), > trotzdem fangen die meisten Menschen dort an, weil sie es leichter > empfinden als die AVR-Programmierung. Entweder assoziieren wir beide etwas völlig Unterschiedliches mit dem Begriff "µC Programmierung" oder dein Vergleich hinkt sehr gewaltig. Auf einem PC fängt man mit der Programmierung an weil man erst einmal FAST NULL vorwissen braucht! Es ist bei den Entwicklungsumgebungen die ich kenne nicht nötig erst einmal die Clock einzustellen, den Bildschirm zu Initialisieren, JA - Nicht einmal erst den Ausgabestream auf den Bildschirm zu routen ist nötig... Für ein erstes "Hallo Welt" ist es nur erforderlich das man weiß wie man die IDE startet und das Programm nach Eingabe der paar Zeichen kompiliert. (kaum ein Anfänger wird heute noch nur auf Kommandozeilenebene mit EInzeltools loslegen - Wenn überhaupt dann nur für ihn unsichtbar als vordefinierte Toolchain was für diesen im Ergbniss ja einer IDE gleichkommt) Das "Schöne" bei der Programmierung am PC ist das man sich erst einmal eine ganze Weile mit den Grundfunktionen einer Programmiersprache austoben kann bevor man über dinge wie Hardwarezugriff usw. nachdenken muss. Selbst das Datei I/O kommt (normalerweise) erst dann wenn man die Grundlagen der Programmierung verstanden hat. Vom Zugriff auf die Schnittstellen ganz zu schweigen. Zudem bekommt man bei den Anfängertypischen Programmen im Fehlerfall immer zumindest eine Eingrnezung wo der Fehler liegt. Könnte in C teilweise deutlicher sein, aber immer noch viel besser als das sich einfach NICHTS tut wie beim µC im Fehlerfall beim Blinkprogramm. Und genau HIER schliesst sich dann auch der Kreis zu den Gründen warum hier für einen Einsteiger wehemennt vertreter der 8Bit Architektur ermpfohlen werden und keine 32Bitter! Es geht um die geringmöglichste Einstiegshürde. Also den Programmieraufwand den man treiben muss und die Zahl der Datenblattseiten die man lesen muss bis man die erste LED blinken lassen und dieses noch auf Tastendruck Aktivieren/Deaktivieren kann. Es mag vielleicht Ausnahmen geben, aber bei den hier genannten 8Bittern ist es deutlich weniger Vorararbeit als bei den hier genannten 32Bittern! Und JA, selbst der 8051 wäre noch ein guter Rat für µC Einsteiger wenn es für diesen genauso eine "Out of the Box" lauffähige kostenlose (Anfängergeiegnete) IDE incl. Compiler, die mit einem 20 Euro Programmer den max 3 Euro teuren µC fast unbegrenzt wiederbeschreiben könnte und dabei natürlich noch die aktive "Community" in den Foren zur Unterstützung hätte wie bei PIC & AVR der Fall. Denn beim Einstieg geht es hier nicht um Leistung des µC sondern einzig und allein erst einmal darum das man Lernt überhaupt damit umzugehen und das ganze Drumherum, gerade den Peripheriezugriff, zu verstehen. Und dieses Verständniss fällt mit einem der hier genannten 8Bitter nun einmal in der Regel als bei den genannten 32Bittern mit Ihrer oft verhandenen wirklichen Fülle an Peripherie bei der natürlich nicht jedes Modul für sich ist sondern viele Module noch zig Abhängigkeiten untereinander haben... Es geht hier doch nicht um eine Entscheidung fürs Leben sondern vielleicht um eine die für die nächsten 365 Tage gilt. Wenn dann die Grundlagen Sattelfest sind kann man ja jederzeit auch auf einen anderen Typ wechseln wenn der Bedarf da ist... Jetzt geht es aber nur darum die Hürden niedrig zu halten. Das der TO innerhalb des nächsten Jahres in die Lage kommt mit überwiegend eigener Firmware die Möglichkeiten eines 8Bitters Sinnvoll auszureizen wage ich mal stark zu bezeifeln. Ach Ja - da hier so die Möglichkeiten der Debugger hervorgehoben wurden. Die sind doch keinesfalls ein Alleinstellungsmerkmal der 32Bitter... Die gibt es doch auch für praktisch jeden halbwegs aktuellen 8Bitter, für die meisten sogar recht günstig. Beim PIC geht es mit ~30 Euro (Original) los, beim AVR meine ich mit dem Dragon für 70(?) Euro... Wobei meiner Meinung nach ein Debugger erst dann richtig Sinn macht wenn man die Grundlagen bereits behrrscht. Also sich schon mal 10 oder 20 Std. mit Blinkprogrammen usw. herumgeschlagen hat. Evtl. könnte man sogar noch weiter gehen und sagen die machen erst dann Sinn wenn man die Struktur des µC wirklich begriffen hat. Aber DANN sind die wirklich eine Hilfe. Ich nutze den Debug Mode bei meinen Programmern sehr selten- Egal ob jetzt PicKit, AVRJTAGII oder Keil JLink. Wenn ich den aber benötige, dann spart der mir oft sehr sehr viel Zeit und Nerven. Gruß Carsten
Ein "Blink-LED" oder "Hello World" sollte man nicht als Maß der Entscheidung nehmen. Viel mehr sollte der TS selbst mal das Datenblatt von einem AVR und einem STM32F103 laden und selbst mal darin lesen wie die Peripherie funktioniert, bzw. was für Möglichkeiten es gibt. Da wird der TO schnell selbst sehen welcher Prozessor besser für IHN geeignet ist, denn was nützt die tollsten Pheriperiefunktinalität wenn man erst mal nur Bahnhof versteht. Ich nutze den STM32 weil ich immer wieder bei Z80/68HC11/8051/AVR/M16C an irgend welche Ecken und Kanten gestoßen bin, die ich mit dem nicht mehr (bzw. viel weniger) habe. Mit einem Debugger kann man jederzeit "Pause" drücken und man sieht wo der Prozessor gerade steht, z.B. hier: Beitrag "Mal wieder Blinkschwierigkeiten beim STM32." Und der TO hätte sofort gemerkt dass die Variable im delayLoop() doch herunterzählt und selbst auf die Idee kommen können mal eine kleinere Zahl zu nehmen. Daher ist ein Debugger auch schon mit den aller ersten Versuchen mehr als Sinnvoll - sofern man versteht was man damit machen kann.
Ach Ja: Um selbst noch eine Empfehlung abzugeben - Bei dem Begriff "Einsteiger" muss man sicher etwas differenzieren, also beispielsweise Unterscheiden ob es sich jetzt um einen ET bzw. INF Studenten im vierten Semester handelt der später seine Brötchen mit µC Anwendungsentwicklung verdienen will oder aber um einen reinen Hobbyisten der es nur zum Spass macht. -Bei "Einsteiger" denke ich normalerweise immer an das zweite, trifft hier ja auch wohl zu ;-) Also hier meine Allgemeinen Überlgegungen: Ich gehöre auch zu denen die für einen EInsteiger erst einmal Latte niedrig anlegen. Also eine 8Bit Architektur. Danach muss man schauen was derjenige Erreichen will. Nur schnell ein paar einfache Aufgaben erfüllen lassen ohne hohen Anspruch darauf auch später viel komplexere Dinge selbst auf die Beine stellen zu können, dann würde der Weg über speziell für Laien gedachte Lösungen am einfachsten sein. Solche Sonderfälle können das Arduino System sein mit teilweise vorgegebener HArdware und besonderer Software, Oder auch nur Dinge wie eine "einfachere Programmiersprache", beispielsweise BASCOM. Solche "Erleichterungen" erkauft man sich aber Üblicherweise mit erheblichen NAchteilen wie das man dann praktisch auf Ewig an einem System festklebt... Oder will man zwar einfach Anfangen, aber kontinuierlich seine Möglichkeiten Ausbauen. Zwar sicher bei komplexen Projekten auch häufig auf fertige Libs zurückgreifen aber in fällen wo es die nicht gibt oder wo die nicht geeignet sind auch selber die Fähigkeiten haben eine Lösung zu liefern an stelle dann zur Aufgabe gezwungen zu sein. (Vom Verständniss der benutzten Libs ganz zu schweigen!) Dann ist derzeit der Einstieg mit der Programmiersprache C bei Programierung direkt auf dem nackten µC das universellste. Die Frage welcher µC für den Einstieg gewählt wird beschränkt in keiner Weise die µC Auswahl für die Zukunft solange für beide ein C Compiler verfügbar ist. -> Da sonst die Auswahl schon beendet wäre gehe ich mal wieder vom zweiten aus Dann denke ich noch das es eine Architektur sein sollte für die es eine Menge Einsteigerfreundliches Lesematerial und Beispiele im Netz gibt, zudem sollten die µC und Programmiertools auch für Privatleute gut beschaffbar sein. -> Die am weitesten verbreiteten µC sind im diesen Sinn wohl AVR und PIC. Dann sollte die Einstiegsausrüstung preislich Erschwinglich sein, denn zum einen ist ja noch nicht sicher ob man wirklich auf dauer Spass an der Sache hat und zum anderen soll es ja auch gerade KEINE Festlegung fürs Leben werden. Zudem gibt es zu viele schöne Dinge im Elektronikbereich zu kaufen als das man ohne Not für etwas viel Geld auf dem Tisch legen sollte wenn es vergleichbares schon viel günstiger Gibt. Das trifft auch auf die beiden Oben genannten µC Familien AVR und PIC zu! Der AVR Programmer koste etwa 40 Euro, einer mit Debugfunktion ab 70Euro. Beim Pic bekommt man ab ~35 Euro einen Programmer/Debugger in einem. Hält sich also beides im Rahmen. -> Beide Familien bleiben im Rennen Zudem ist es ja durchaus so das gerade im Einstig häufiger mal der µC stirbt. Gemeinerweise aber häufig nicht komplett, sondern nur ein einzelner Pinntreiber usw. weil ein Port statt auf Eingang als Ausgang eingestellt war mit Kurzschluss als Folge usw. Daher denke ICH das es sehr Ratsam ist die ersten Gehversuche mit einem gesockelten µC im DIP gehäuse zu absolvieren. Das erleichtert den Austausch kaputter µC oder auch nur die Gegenprobe ob ein Fehler nun in der SW oder in der HArdware des µC liegt. Auch können so viel leichter erste eigene Schaltungen auf Lochraster aufgebaut werden... Und für Elektronikeinsteiger gilt das erst RECHT! Denn da fehlt sowohl die Lötübung für den Aus/Einbau von SMD µC mit hohem PinCount als auch die Erfahrung im Schaltungsaufbau allgemein was sicher den einen oder anderen kaputten µC mehr zur Folge haben wird. ->Auch das Feature "Vieles noch in DIP" bieten beide Familien PIC & AVR die in der engeren Auswahl sind. (Wobei auch hier die PIC leicht die NAse vorn haben da auch neue µC immer noch in DIP aufgelegt werden wenn die mit max 40Pin Auskommen) Damit gibt es KEINEN klaren Sieger. Ich mache das dann immer noch an den "Sprachfähigkeiten" fest. Wer gut Englisch kann dem würde ich im allgemeinen eher zum PIC raten weil er doch bei den Anfängerkriterien leicht vorne liegt. Zudem ist es ja noch so das PIC nicht eine einzelne Controllerserie meint sondern das es ein Oberbegriff für verschiedene Serien eines HErstellers ist die alle mit derselben IDE und mittlerweile für den Anweder identischen Compilern über denselben Programmer programmiert werden. Hier kann man also mit einem 18F 8Bitter einsteigen, nach ein paar Wochen Übung mit derselben Entwicklungsumgebeung und der selben Programmierhardware dann einen Leistungsfähigen 32Bitter bearbeiten und direkt danach dann noch extrakleinen 8Bitter im SOT23/5 Gehäuse verwenden... (Wobei dieses Argument für einen Einsteiger nur sehr beschränktes Gewicht haben sollte bei den heutigen Programmerpreisen!) Wer aber kaum Englisch kann hat im µC Bereich zwar allgemein Probleme - fährt aber mit dem AVR durch die viel größere deutsche Community zumindest etwas besser. -> Aber wie gesagt: Das war die Allgemeine Beurteilung Im konkreten Fall bin ich aber geneigt eine ANDERE Empfehlung in Erwägung zu ziehen. Da der TE ja ausdrücklich schrieb das er keine nennenswerte Elektronikkentnisse hat scheidet zumindest für den Anfang der Aufbau eigener Schaltungen aus. Es bliebe also nur der Weg "erst" einmal Elektronikkenntnisse incl. Lötarbeiten zu sammeln und Später mit den µC zu beginnen. Für jemanden den aber die Programmierung in erster Linie interessiert vielleicht zu Langweilig... Auch Entwicklungsboards alleine sind keine befriedigenge Lösung, da sie für der allerersten Kontakt sicher eine Hilfe dadurch sind das die Schaltung passend Dimensioniert und Fehlerfrei ist, aber für viele eigene Anfängerprojekte zu Unflexibel. Allgemein gibt es ja die "starter Kits" als Schnupperhardware und dann die wirklich hochkomplexen Boards die ich bei vielen (beruflichen) Projekten für die ersten Schritte nicht mehr missen möchte. Aber nur wenig im mittleren Bereich wohl sich der TE im nächsten JAhr wohl man meisten bewegen wird. Daher würde ich IN DIESEM SPEZIELLEN FALL doch auf die oben eigendlich bereits ausgeschlossene Arduino Plattform zurückkommen um diese noch einmal mit ins Gespräch zu bringen. Es wurde ja schon mehrfach geschrieben das man diese Serie ja nicht "nur" als "Arduino" Gesamtprojekt sehen kann sondern das es sich üblicherweise um Boards mit einem vorprogrammierten ATMEGA 328 handelt die man auch mit nativen C aus dem AVR Studio herraus programmieren kann. Daher erscheint mir der Griff zu den ARDUINO Boards hier durchasu Sinnvoll. Idealerweise eines mit Gesockeltem µC! (Oder Notfalls halt mehrere in Reserve halten um schnell mal zur Kontrolle querzutauschen) Allerdings würde ich dem TE dann sehr ans HErz legen die ganze Arduino Software links liegen zu lassen und die Boards wirklich nur als HArdwareplattform zu verwenden, die Programmentwicklung im AVR Studio vorzunehmen usw. Das ist vermutlich der beste Kompromiss aus einfachen Einstieg ohne Elektronikkentnisse, Erweiterbarkeit (Er kann ja auch die "Arduino Shields" problemlos verwenden) aber auch der Möglichkeit sich alle Optionen offen zu halten und ohne große Probleme später auf eine Leistungsfähigere µC Famile umzusteigen wenn er wirklich entsprechend Ressourcenhungrige Firmware schreibt. Gruß Carsten
@Carsten: 10 Pluspunkte für Deine ausführliche Stellungnahme. Wenn der TO mit einem 8051-Derivat starten würde, wäre das aus meiner Sicht auch in Ordnung.
Future schrieb: > Lies deine Posts. Lies DU meine Posts: Andreas H. schrieb: > Ich hab mich hier nur hauptsächlich auf diese beiden Typen bezogen, weil > dass Thema des Threads ja eigentlich in die Frage abdriftete, was für > einen Anfanger besser ist. Ansonsten wären wir nämlich schon bestimmt bei dem Thema angelangt, warum Du jedem auf biegen und brechen einen STM32 aufschwatzen willst, wenn man für den gleichen Preis auch einen Stellaris (Cortex-3) oder (besser) einen Tiva (Cortex-4) bekommt. (Dann landen wir aber natürlich sofort bei der berühmten Fangfrage, wie man mit einem STM32 PCI auf level (statt edges) auslöst usw., usw. ). Oh, und PIC32 (MIPS-4K) wäre auch noch im Angebot. Den gibts auch noch im bastelfreundlichen DIL28 ;-) Aber das bringt den TO auch nicht weiter^^ Antimedial schrieb: > Die CPU > eines Raspberry Pi ist auch unheimlich komplex, trotzdem kann man einem > Anfänger innerhalb weniger Stunden erste Schritte beibringen. Und zwei Stunden später daran verzweifeln, dass er es nicht schafft, ein simples TFT (z.B. mit HD44780) anzuschließen, ohne sich entweder erst mal in den Linuxkernel reinlesen zu müssen oder auf der /sys/gpioXX Ebene rumzukratzen. Und damit lernt jemand Embedded programming ? Wohl kaum. Antimedial schrieb: > Ein PC ist > auch unheimlich komplex (übrigens 64 Bit heutzutage meistens), trotzdem > fangen die meisten Menschen dort an, weil sie es leichter empfinden als > die AVR-Programmierung. Dann lass mal mit einem Standard-PC eine LED blinken. Das ist ein Äpfel<->Birnen Vergleich, oder ? basics schrieb: > Carsten Sch. schrieb: > > Volle Zustimmung! m.n. schrieb: > @Carsten: > 10 Pluspunkte für Deine ausführliche Stellungnahme. Ja, Carsten hat den Nagel 100% auf den Kopf getroffen. Genau meine Meinung. m.n. schrieb: > Wenn der TO mit einem 8051-Derivat starten würde, wäre das aus meiner > Sicht auch in Ordnung. Etwas offtopic aber gibts eigentlich in der Zwischenzeit "bezahlbare" Compiler für die 8051, MCS81 usw. ? Der Keil ist ja sehr nett aber etwas teuer für Zuhause. Grüße Andreas
Warum ist die Peripherie des stm32 eigentlich schwer zu nutzen? Die Initialisierung ist doch dermaßen leicht mit der St Lib zu bewerkstelligen. Da kann man ja mehr oder weniger in Klartext hinschreiben was man will... Seit ich den stm32 nutze, gucke ich nur noch ganz selten ins Datenblatt, denn die Initialisierungen stehen alle schön ordentlich in der Lib drinnen. Ich mache es meistens so: Initialisierungen mit den Lib-Funktionen und wenn es etwas schneller gehen soll (zb. Pin Togglen), dann gucke ich in die Funktion rein die das machen soll und kopier mir das Wesentliche da raus. Super simpel. Alles gelingt traumhaft einfach. Sogar DMA-Zugriffe sind sehr leicht zu machen. Und was hier immer von "Es ist doch so kompliziert den Clock einzustellen" geredet wird: Was ist daran so komplex die Zeile "SystemInit();" im Main einzufügen und an 2 Stellen im Code eine Variable auf den verwendeten Quarz zu ändern? Da hatte ich tagelange nervenzermürbenden Ärger mit den Drecks AVR-Fuses. Als Einsteiger kann man da schon verzweifeln, wenn nichts mehr geht. Da lobe ich mir ein einfach zu nutzendes stm32 Discovery, wo in Null Komma Nix eine LED blinkt. Ohne Stress, günstig und zukunftsweisend.
Andreas H. schrieb: > warum Du jedem auf biegen und brechen einen STM32 aufschwatzen willst Wer will denn das? Es waren auch andere Controller im Gespräch. Du hast nur noch nicht verstanden, dass 32 Bit nicht gleichzusetzen mit "kompliziert" ist. Die Zeit bleibt nicht stehen. 32 Bit werden ganz normal. ;-) Und lies den folgenden Abschnitt ruhig mehrmals, damit es hängen bleibt. ;-P lusi schrieb: > Da hatte ich tagelange nervenzermürbenden Ärger mit den Drecks > AVR-Fuses. Als Einsteiger kann man da schon verzweifeln, wenn nichts > mehr geht. Da lobe ich mir ein einfach zu nutzendes stm32 Discovery, wo > in Null Komma Nix eine LED blinkt. Ohne Stress, günstig und > zukunftsweisend.
Stefan Tully schrieb: > ich bin absoluter Neueinsteiger in die Welt der Elektronik und > Mikrocontroller Programmierung. Ein bisschen Programmierung habe ich in > C, C+, Basic und VBA das ist aber auch schon alles ziemlich lange her. > Auf meine alten Tage möchte ich mir nun nochmal ein neues Hobby zulegen Eigentlich ist es für Deinen Zweck egal mit welchen Chip Du anfängst. Höre Dich mal unter Deiner Bekannschaft um ob sich auch jemand mit solchen Dingern befaßt und Dir bei den ersten Gehversuchen helfen kann. Das dürfte Dir den Einstieg erheblich erleichtern. Mein erster war ein 6502 ...
lusi schrieb: > Da lobe ich mir ein einfach zu nutzendes stm32 Discovery, wo > in Null Komma Nix eine LED blinkt. Ohne Stress, günstig und > zukunftsweisend. <irony> Na wenn das Deine Anfordungen erfüllt kann ich Dir was preiswerteres anbieten: http://www.reichelt.de/?ARTICLE=22270&PROVID=2257&wt_mc=amc136152448016369&ref=adwords_pla&&gclid=CPCr_sG20LsCFUhb3godg1cApg </irony> Ich weiss nicht, ob es mir icht mehr Sorgen machen würde, an den paar AVR Fuses zu scheitern, was vermutlich jedem, der mit AVRs anfängt, schon passiert ist. Meist weil man doch noch nicht richtig begriffen hat, was in diesem 8-Bit "Teufelswerk" abgeht. Probier vielleicht mal etwas, wo man schon eher 32-Bit braucht. Z.B. mit zwei Mikrophonen eine zuverlässige (!) Ortsbestimmung einer Schallquelle zu machen. Hint: http://de.wikipedia.org/wiki/Lokalisation_(Akustik) Oder (wenns etwas anspruchsvoller sein darf) einen Lämschutzkopfhörer, der zwar Lärm aktiv wegdämpft, Sprache aber noch durchlässt. Viel Spass (auch mit den latenzen ;-) Grüße Andreas
Joachim Drechsel schrieb: > Höre Dich mal unter Deiner Bekannschaft um ob sich auch > jemand mit solchen Dingern befaßt und Dir bei den ersten Gehversuchen > helfen kann. Das dürfte Dir den Einstieg erheblich erleichtern. Stimmt :-) Auf diese Idee sind wir bei unserem ganzen "Rumgezanke" gar nicht gekommen. Viele Probleme werden ja schon im Keim erstickt, wenn sie mit einem kurzen Anruf erledigt werden können. Erspart u.U. viel rumgesuche im Netz. Grüße Andreas
Andreas H. schrieb: > Ich weiss nicht, ob es mir icht mehr Sorgen machen würde, an den paar > AVR Fuses zu scheitern, was vermutlich jedem, der mit AVRs anfängt, > schon passiert ist. ??? Andreas H. schrieb: >Meist weil man doch noch nicht richtig begriffen > hat, was in diesem 8-Bit "Teufelswerk" abgeht. Und daher perfekt für Anfänger. :-( :-( :-(
Carsten Sch. schrieb: > Entweder assoziieren wir beide etwas völlig Unterschiedliches mit dem > Begriff "µC Programmierung" oder dein Vergleich hinkt sehr gewaltig. Andreas H. schrieb: > Dann lass mal mit einem Standard-PC eine LED blinken. > Das ist ein Äpfel<->Birnen Vergleich, oder ? Schade, ihr habt beide nicht begriffen, was ich damit sagen wollte. Dabei habe ich es eigentlich gleich im ersten Satz gesagt: Man kann Komplexität verbergen! Wenn man es richtig macht, kann man auch ein deutlich komplexeres System (eben Raspberry Pi oder ein PC) sehr gut beherrschen. Die Frage ist also nicht, wie komplex das System ist, sondern wie einfach der Einstieg in das System ist. Und wie bereits erwähnt, gibt es bei Cortex-M-µC meistens Standardbibliotheken und sehr gute Beispiele, die für einen Einsteiger bzw. "Umsteiger" aus dem PC-Bereich womöglich sogar einfacher zu verstehen sind als die nackten Register bei einem AVR. Und deshalb ist es erst einmal Unsinn 32-Bit von vorne rein auszuschließen, sondern sind durchaus eine Erwägung wert. Eben weil sie auch deutlich mächtigere Anwendungen ermöglichen. Oder mal ehrlich, wer will denn nur eine LED blinken lassen? Um es noch einmal klarzustellen: Ich will hier keinem vom AVR zum Einstieg abraten, ich bin nur dagegen, dass man 32-Bit-µC von vornerein als zu komplex abtut.
Andreas H. schrieb: > Auf diese Idee sind wir bei unserem ganzen "Rumgezanke" gar nicht > gekommen. > Viele Probleme werden ja schon im Keim erstickt, wenn sie mit einem > kurzen Anruf erledigt werden können. So isses ... ;)
Joachim Drechsel schrieb: > Andreas H. schrieb: >> Auf diese Idee sind wir bei unserem ganzen "Rumgezanke" gar nicht >> gekommen. >> Viele Probleme werden ja schon im Keim erstickt, wenn sie mit einem >> kurzen Anruf erledigt werden können. > > So isses ... ;) So, und jetzt geh ich meinen AIM-65 mal "streicheln" (u remember that ?) :-D Grüße Andreas
lusi schrieb: > Da lobe ich mir ein einfach zu nutzendes stm32 Discovery, wo > in Null Komma Nix eine LED blinkt. Mit dem STM32F407-Discovery hatte ich vor ca. zwei Jahren angefangen. Zu meiner großen Freude blinkten da schon LEDs und ich brauchte nichts mehr zu programmieren. So einfach ist das :-) Anschließend hatte ich damit eine Anwendung umgesetzt, die schon auf Renesas µCs (H8SX, SH2 und RX) lief, und wo ich genau wußte, was mein Ziel war. Und dennoch war es eine elende Sucherei, die gewünschten Dokumente zu finden. Ferner fiel mir auch auf, dass die STM32 keine Alleskönner sind, sondern gegenüber den zuvor genannten Controllern teilweise deutliche Einschränkungen aufweisen. Das merkt man aber erst, wenn man mal mehr anstellt, als fertige Beispielprogramme zusammenzuklicken (siehe blinkende LED). Einem Anfänger den STM32F4xx als Einstieg zum empfehlen soll wohl nur dem einen Zweck dienen: die eigene Programmierpotenz zur Schau zu stellen.
m.n. schrieb: > Anschließend hatte ich damit eine Anwendung umgesetzt, die schon auf > Renesas µCs (H8SX, SH2 und RX) lief, und wo ich genau wußte, was mein > Ziel war. > Und dennoch war es eine elende Sucherei, die gewünschten Dokumente zu > finden. Ferner fiel mir auch auf, dass die STM32 keine Alleskönner sind, > sondern gegenüber den zuvor genannten Controllern teilweise deutliche > Einschränkungen aufweisen. Das klingt eher so, als wäre die Vorgehensweise durch deine vorgegebene Lösung schon so in Stein geklopft, dass du die Möglichkeiten des µC gar nicht richtig genutzt hast. m.n. schrieb: > Einem Anfänger den STM32F4xx als Einstieg zum empfehlen soll wohl nur > dem einen Zweck dienen: die eigene Programmierpotenz zur Schau zu > stellen. Dieser Schluss entbehrt sich jeglicher Logik.
m.n. schrieb: > Einem Anfänger den STM32F4xx als Einstieg zum empfehlen soll wohl nur > dem einen Zweck dienen: die eigene Programmierpotenz zur Schau zu > stellen. Ich denke eher, daß die weit Fortgeschrittenen und Profis schon zu weit von den Anfängen entfernt sind und sich nicht vergegenwärtigen, daß die eigenen z.T. sicher auch unbewußten Selbstverständlichkeiten für den Anfänger große Hürden darstellen können.
m.n. schrieb: > > Einem Anfänger den STM32F4xx als Einstieg zum empfehlen soll wohl nur > dem einen Zweck dienen: die eigene Programmierpotenz zur Schau zu > stellen. Sehe ich ganz genau so! Man sind das alles Helden. 700 Seiten Datenblatt, AppNotes und was sonst noch. Da ist so ein kleiner Tiny mit 170 Seiten noch recht überschaubar. Worum geht es denn zu Anfang? Doch sicher nicht darum einen Mars Rover zu bauen. Natürlich kann ein Anfänger auch einen Code programmieren und den auf einen STM32 bekommen und auf dem Discovery wird es auch blinken, aber es geht doch um so viel mehr. Man wird sich unweigerlich mit der Elektronik als solche auseinander setzten, wird auf einmal erfahren was ein OP ist, wozu man ihn einsetzt und was man da alles machen muss. Es geht darum die Architektur verstehen zu lernen. Und nicht zuletzt, wie löte ich richtig. Da sind noch so irre viele Hürden zu nehmen, die ihr Helden längst vergessen habt. Ich arbeite seit 25 Jahren mit Elektrik und Elektronik, aber selbst das Löten musste ich noch mal einen Tag lang üben. Jetzt löte ich auch 0805 von Hand, aber zu Anfang war selbst ein Sockel schwierig. Ob nun Atmel oder so ein MSP430 oder was auch immer, Hauptsache der Käfer hat erstmal Beine. Bücher gibt es sicher schon genug zum STM32, vor allem die Chinesischen Ausgaben kann ich da empfehlen. Warum wohl sind der Professor Banzi und die Gruppe um ihn auf die Idee gekommen diese Arduino Sachen zu bauen? Am besten ist es sicherlich ein fertiges Gerät zu kaufen in dem schon ein Cortex drin ist und das auch ordentlich blinkt und irgendwas macht. In allererster Linie geht es ums Lernen und Verstehen, später kann der Erfahrene dann ja immer noch den superduperhighend Mikrocontroller nehmen und damit das nächste Weltwunder aufbauen.
> Ich arbeite seit 25 Jahren mit Elektrik und Elektronik, aber selbst das > Löten musste ich noch mal einen Tag lang üben. Jetzt löte ich auch 0805 > von Hand, aber zu Anfang war selbst ein Sockel schwierig. > Ob nun Atmel oder so ein MSP430 oder was auch immer, Hauptsache der > Käfer hat erstmal Beine. SMD ist einfacher/schneller zu löten als bedrahtet.
Antimedial schrieb: > Carsten Sch. schrieb: >> Entweder assoziieren wir beide etwas völlig Unterschiedliches mit dem >> Begriff "µC Programmierung" oder dein Vergleich hinkt sehr gewaltig. > > Andreas H. schrieb: >> Dann lass mal mit einem Standard-PC eine LED blinken. >> Das ist ein Äpfel<->Birnen Vergleich, oder ? > > Schade, ihr habt beide nicht begriffen, was ich damit sagen wollte. > Dabei habe ich es eigentlich gleich im ersten Satz gesagt: Man kann > Komplexität verbergen! Wenn man es richtig macht, kann man auch ein > deutlich komplexeres System (eben Raspberry Pi oder ein PC) sehr gut > beherrschen. Doch, begriffen was du meintest habe ich durchaus. Für Andreas kann ich nicht sprechen, vermute aber mal er auch. JA- Komplexität kann man zu einem gewissen Grad verbergen. Aber das funktioniert nur gut so lange man dann auch auf der Abstraktionsebene bleibt auf der sich das alles abspielt! Sobald man aber an den Punkt kommt wo man auf eine niedrigere Ebene wechseln muss oder auch nur möchte fährt man direkt vor die Wand wenn man die Grundlagen nicht beherrscht. Das oben genannte Beispiel mit dem "LED am PC Druckerport blinken lassen" finde ich da schon ganz passend. Dank der Abstraktion kann man die tollsten Sachen mit wenig Aufwand auf dem PC zu stande bringen. Aber ich wette ein einfaches PinToggeln bekommen die meisten "PC-Programmierer" ohne Nachschlagen nicht hin - Falls überhaupt in vertretbarer Zeit. Und deshalb meine Bemerkung mit dem "Verständniss" des Begriffes "µC Programmierung". Bei den typischen Anfängerprojekten geht es doch eher selten um die Entwicklung eines MultimediaHsimsystems mit achweißichnichtwieviel Zoll TFT sondern eher um kleine Anwendungen mit einfacher Pinabfrage, ggf mal einen Timer, wenn es dann fortschrittlicher wird noch SPI, PWM oder gar UART. Bis man aber an den Punkt angelangt ist wo man dann die oben genannten Funktionen wirklich verstanden und endlich auch komplexere Projekte angehen kann sind mit Sicherheit viele viele viele Nachmittage vergangen an denen man sich auf der untersten Hardwareebene herumtreiben musste. > Und wie bereits erwähnt, gibt es bei Cortex-M-µC meistens > Standardbibliotheken und sehr gute Beispiele, die für einen Einsteiger > bzw. "Umsteiger" aus dem PC-Bereich womöglich sogar einfacher zu > verstehen sind als die nackten Register bei einem AVR. JA - Aber wie oben schon geschrieben: Wenn man mit diesem Grundsatz an die Sache ran geht, dann lernt man den Umgang mit der Bibliothek aber nicht die wirklichen Grundlagen. Und was die Lib nicht her gibt, das geht dann nicht - Oder wie? Selbstverständlich ist es heute nicht mehr Zeitgemäß komplexe Projekte auf der untersten Ebene abzuwickeln. Es ist auch aus meiner Sicht eine enorme Erleichterung das es diese Libs gibt und mittlerweile sind die für mich sogar zu einem wichtigen Kriterium bei der µC Auswahl für ein Projekt geworden. ABER: Eine sinnvolle Anwendung erfordert meist sowohl den Einsatz der vorgefertigten Libs als auch eine sachkundig erbrachte Eigenleistung. Und diese Eigenleistung ausserhalb der Lib-Anwenunge kann man ab einem bestimmten Schwierigkeitsgrad nur erbringen wenn man die Basics kennt. > Oder mal ehrlich, wer will denn nur eine LED > blinken lassen? Nur eine LED Blinken lassen will auf Dauer sicher niemand! Aber zum Einstieg ist dies nun einmal der erste sinnvolle Schritt. Und eine ganze Reihe der dann folgenden Projekte bewegen sich aus sicht eines "erfahrenen" Anwenders auch nur auf einer sehr ähnlichen Ebene. Wie gesagt, es geht nicht darum das jemand auf Dauer nur mit 8Bit µC arbeiten soll. Es geht hier nur um eine Plattform zum erlernen der BASICS zum Einstieg. Denn wer die BASICS beherscht hat keinerlei größere Probleme sich auf den unterschiedlichsten Architekturen zurechtzufinden und immer wieder neu GENAU DIE Architektur auszuwählen die für das aktuelle Projekt die geeigneteste ist. Das Problem mit der "Eine für ALLES" Auswahl haben nur diejenigen die, weil sie so tolle Hechte sind, sich nie dazu "herabgelassen" haben sich mit den Tiefen der Materie zu beschäftigen. Gruß Carsten
lusi schrieb: >> Ich arbeite seit 25 Jahren mit Elektrik und Elektronik, aber selbst das >> Löten musste ich noch mal einen Tag lang üben. Jetzt löte ich auch 0805 >> von Hand, aber zu Anfang war selbst ein Sockel schwierig. >> Ob nun Atmel oder so ein MSP430 oder was auch immer, Hauptsache der >> Käfer hat erstmal Beine. > > SMD ist einfacher/schneller zu löten als bedrahtet. Ja, empfinde ich jetzt auch so, aber vor zwei Jahren waren normale Transistoren (TO92) noch winzig für mich und heute finde ich SOT23 schon recht griffig. Daran sieht man aber, dass du so lange von der Basis weg bist, dass du das einfach nicht mehr weißt.
> Und was > die Lib nicht her gibt, das geht dann nicht - Oder wie? die Lib umfasst im Grunde alles. Wenn es dann doch mal in Ausnahmefällen nicht geht, guckt man halt ins Datenblatt. Mir ist bislang noch nichts untergekommen, was mit der Lib nicht geht. Was sollte das denn sein?
Carsten Sch. schrieb: > Das oben genannte Beispiel mit dem "LED am PC Druckerport blinken > lassen" finde ich da schon ganz passend. Dank der Abstraktion kann man > die tollsten Sachen mit wenig Aufwand auf dem PC zu stande bringen. Ok, du hast es nicht begriffen. Es ging nie darum zu behaupten, dass man mit einem PC oder einem Raspberry Pi typische µP-Aufgaben erledigen kann. Diese Systeme nimmt man natürlich für ganz andere Aufgaben! Carsten Sch. schrieb: > Wenn man mit diesem Grundsatz an die Sache ran geht, dann lernt man den > Umgang mit der Bibliothek aber nicht die wirklichen Grundlagen. Und was > die Lib nicht her gibt, das geht dann nicht - Oder wie? Und was die Peripherie und der Kern des AVR nicht hergibt, geht halt eben auch nicht. Beim STM32 hätte man dann aber die Möglichkeit, tiefer zu gehen. Beim AVR ist man aufgeschmissen.
lusi schrieb: > Da hatte ich tagelange nervenzermürbenden Ärger mit den Drecks > AVR-Fuses. Als Einsteiger kann man da schon verzweifeln, wenn nichts > mehr geht. Seltsam das war bei mir genau umgekehrt: Die Fuses hab ich zum ersten mal nach einem halben Jahr verschossen. Davor hab ich immer zwei mal geschaut, bevor ich die verändert habe. > Da lobe ich mir ein einfach zu nutzendes stm32 Discovery, wo > in Null Komma Nix eine LED blinkt. Ohne Stress, günstig und > zukunftsweisend. Nach 2 Tagen bis der Compiler mal endlich bei eigenen Testprojekten lief, funktionierten die fertigen Codebeispiele immernoch nicht. Da ging bei mir langsam die Motivation flöten. Beim Avr heißt es runterladen, installieren und alles funktioniert. Und dann soll STM32 einfacher sein??? Das Preisargument bei 32bit verstehe ich bis heute noch nicht. Atmega48 für < 1€ reicht für die meisten Projekte. Für ganze große Sachen gibts z.B. den Xmega192 für unter 3€. Und man hat keine Probleme mit irgendeiner komplizierten IDE, da kostenlos vom Hersteller verfügbar. Btw. mit welchem µC hast du denn angefangen? Sicherlich nicht mit STM32.
> Nach 2 Tagen bis der Compiler mal endlich bei eigenen Testprojekten > lief, funktionierten die fertigen Codebeispiele immernoch nicht. Da ging > bei mir langsam die Motivation flöten. Beim Avr heißt es runterladen, > installieren und alles funktioniert. Und dann soll STM32 einfacher > sein??? Coocox lief bei mir auf Anhieb. Aber jeder macht da halt so seine Erfahrungen. Ist ja auch ein bischen vom Zufall abhängig...
Antimedial schrieb: > Und was die Peripherie und der Kern des AVR nicht hergibt, geht halt > eben auch nicht. Beim STM32 hätte man dann aber die Möglichkeit, tiefer > zu gehen. Beim AVR ist man aufgeschmissen. Was ist denn, wenn die Peripherie vom STM32 nicht das hergibt, was der AVR hergibt? Beispielsweise das Event System, mit dem man sehr flexibel interne Peripherieeinheiten wie Timer zusammenschalten kann. Das kann nämlich der STM32 nicht, aber der XMEGA. Bei unserem Chameleon Projekt habe ich genau davon nämlich extensiven Gebrauch gemacht. Der STM32 stand zu Anfang des Projektes auch zur Debatte aber aus genau dem Grund fiel die Entscheidung auf den XMEGA. https://github.com/skuep/ChameleonMini/wiki
:
Bearbeitet durch User
Simon K. schrieb: > Was ist denn, wenn die Peripherie vom STM32 nicht das hergibt, was der > AVR hergibt? Beispielsweise das Event System, mit dem man sehr flexibel > interne Peripherieeinheiten wie Timer zusammenschalten kann. Das kann > nämlich der STM32 nicht, aber der XMEGA. Timer zusammenschalten kann man beim STM32 auch. Davon abgesehen sind die Timer an sich schon mächtiger, dass man wahrscheinlich in den allermeisten Fällen nicht in die Verlegenheit gerät. Ansonsten ist es schon klar, dass es in den Peripherien immer Unterschiede geben wird und man sicherlich irgend ein Beispiel findet, bei dem man einen Controller nicht so gut einsetzen kann. Das sind dann aber meist Ausnahmen, die die Regel bestätigen.
>Mein erster war ein 6502 ... Meiner auch! Es dürfte wirklich nicht besonders günstig für einen Anfänger sein, ihn mit 16- und 32-Bit-Controllern zu bombardieren, sag ich mal. Für den Einstieg reicht ein 8-Bit-Controller auf jeden Fall. Auch für die meisten Hobby-Anwendungen. Was mich ein wenig konsterniert, sind die ständigen Hinweise auf die Datenblätter, wobei die Bezeichnung gar nicht stimmt, denn es handelt sich dabei meist um ein Buch mit mehreren hundert Seiten. Was soll ein Anfänger mit diesen komplexen Unterlagen? Wie soll er herausfiltern, was da wichtig ist, abgesehen davon, dass er bestimmt nicht weiss, wie er die Daten in ein Programm umsetzt. In dem Punkt hilft Stefan sehr: http://www.youtube.com/watch?v=kAnp2n2o60Y Er zeigt sehr gut, worauf es prinzipiell ankommt, präsentiert seine Tutorials äusserst verständlich und führt gleichzeitig prima in die Programmiersprache C ein. Ich glaube, dass man genau hier für einen Anfänger ansetzen sollte. Auch die Datenblätter in deutscher Sprache wären recht praktisch, aber, für die Files auf dem angegebenen Link braucht man leider ein Kennwort.
Antimedial schrieb: > Simon K. schrieb: >> Was ist denn, wenn die Peripherie vom STM32 nicht das hergibt, was der >> AVR hergibt? Beispielsweise das Event System, mit dem man sehr flexibel >> interne Peripherieeinheiten wie Timer zusammenschalten kann. Das kann >> nämlich der STM32 nicht, aber der XMEGA. > > Timer zusammenschalten kann man beim STM32 auch. Davon abgesehen sind > die Timer an sich schon mächtiger, dass man wahrscheinlich in den > allermeisten Fällen nicht in die Verlegenheit gerät. Ja, mächtiger sind sie. Ich blicke da auf die Schnelle nicht ganz durch, aber sehe keine Möglichkeit wie ein Timer mit einem externen Trigger durch einen anderen Timer zurückgesetzt werden kann. Wie auch immer, so flexibel wie mit dem Event System vom XMEGA geht das wohl kaum. > Ansonsten ist es schon klar, dass es in den Peripherien immer > Unterschiede geben wird und man sicherlich irgend ein Beispiel findet, > bei dem man einen Controller nicht so gut einsetzen kann. Das sind dann > aber meist Ausnahmen, die die Regel bestätigen. Aber diese Ausnahmen sind eben auch relevant für die Auswahl des Mikrocontrollers für eine gegebene Aufgabe.
Antimedial schrieb: > Schade, ihr habt beide nicht begriffen, was ich damit sagen wollte. Keiner versteht Dich ? Du Armer ;-) > Man kann Komplexität verbergen! Aber will man das ? Du programmierst doch einen embedded uP nicht aus Jux und Tollerei. Das Ding hat eine Aufgabe. Und die ist meist nicht "Schreib 'Hello world' auf das TFT oder "lass mal die LED blinken". Die meisten Probleme kannst Du doch nur noch lösen, wenn Du sie verstehst. Und dann, in einer Fehlersituation, fängt man an, sich mit der Hardware des uPs zu beschäftigen, die ja vorher so elegant gekapselt war ? Vielleicht doch etwas spät, oder ? Ein Beispiel ? Hier: Antimedial schrieb: > Das klingt eher so, als wäre die Vorgehensweise durch deine vorgegebene > Lösung schon so in Stein geklopft, dass du die Möglichkeiten des µC gar > nicht richtig genutzt hast. Da hast Du vermutlich recht, weil m.n. ja vorher schreibt: m.n. schrieb: > Mit dem STM32F407-Discovery hatte ich vor ca. zwei Jahren angefangen. Zu > meiner großen Freude blinkten da schon LEDs und ich brauchte nichts mehr > zu programmieren. So einfach ist das :-) q.e.d. Viele haben es schon geschrieben und F.Fo. bringts nochmal auf den Punkt: F. Fo schrieb: > Da sind noch so irre viele Hürden zu nehmen, die ihr Helden längst > vergessen habt. Jeder der erst mal für €10-20 mit 8-Bit anfängt wird zu gegebener Zeit auch 32-Bit machen, wenn er es braucht. Aber dann hat er den 8-Bitter schon richtig "ausgeknautscht" und wird den 32-Bitter vermutlich wesentlich besser in den Griff kriegen, als die "Look mom, only $10, 32Bit for that blinking LED" Anfänger, die nachher verzweifelt das vermeintlich kaputte Board tauschen, weil sie versehentlich den Bootloader gekillt haben und nicht mal wussten, dass sie einen hatten. Nicht vergessen: F. Fo schrieb: > In allererster Linie geht es ums Lernen und Verstehen ... und nicht um die superpreiswerteste Lösung nicht existierender Marketingphantasien. Grüße Andreas
Antimedial schrieb: > > Ok, du hast es nicht begriffen. Also entweder verstehen Dich die Leute nicht oder sie haben es nicht begriffen. Seltsames Massenphänomen. > Carsten Sch. schrieb: >> Wenn man mit diesem Grundsatz an die Sache ran geht, dann lernt man den >> Umgang mit der Bibliothek aber nicht die wirklichen Grundlagen. Und was >> die Lib nicht her gibt, das geht dann nicht - Oder wie? > > Und was die Peripherie und der Kern des AVR nicht hergibt, geht halt > eben auch nicht. Beim STM32 hätte man dann aber die Möglichkeit, tiefer > zu gehen. Beim AVR ist man aufgeschmissen. Nee, dann nimmt man eben einen gößeren uP. Den AVR hat man dann ja wohl so ausgeknautscht das es eben nicht geht, dabei aber auch gut verstanden. Aber was macht der arme STM32 User in dieser Situation ? Vielleicht doch mal auf Registerebene (Bäh), mit ASM (Pfui) die typischen 1-2% high-criticals per Hand nachoptimieren ? Natürlich erst nachdem er einige Wochen versucht hat seinen "STM32 -Das Unbekannte aus der Tiefe" wirklich zu verstehen. Wie schon mehrfach gesagt: LIBS & 32Bit sind toll, wenn man sie versteht. Aber erst dann. Grüße Andreas
>Stefan Tully, liest du eigentlich noch mit?
Der hat keine Zeit mehr -er programmiert schon den 10. Kontrollertyp.
>Stefan Tully, liest du eigentlich noch mit?
Wisst ihr was? ;-) Sadisten seid ihr! Der arme Stefan hat sich längst
woanders herumgegoogelt! ;-) Wollt ihr wirklich alle Anfänger auf diese
Art verscheuchen? Die Methodik finde ich nicht gut.
Und der böse Kasten-Sektierer ;-) Naja, er scheint aber grosses Wissen
zu haben.
Andreas H. schrieb: > Jeder der erst mal für €10-20 mit 8-Bit anfängt wird zu gegebener Zeit > auch 32-Bit machen, wenn er es braucht. Ein AVR braucht mehr finazielle Zuwendung. Erst recht als Anfänger, wenn es "out fo the box" sein soll. > > Aber dann hat er den 8-Bitter schon richtig "ausgeknautscht" und wird > den 32-Bitter vermutlich wesentlich besser in den Griff kriegen Und alle müssen mit einem Nissan Micra als erstes Auto anfangen. Wenn der "ausgeknautscht" ist und nicht mehr reicht, darf man vorsichtig nach einem Golf fragen. :-((( Warum traust du anderen nix zu? In ein paar Jahren suchst du hinter den AVRs genauso hinterher wie heute bei den 68k. Alles zu seiner Zeit! Und jetzt ist die Zeit für 32 Bit, auch für Anfänger. Oder hast du Angst überholt zu werden? >;->>>
Blende22-Mint schrieb: >>Stefan Tully, liest du eigentlich noch mit? > > Wisst ihr was? ;-) Sadisten seid ihr! Der arme Stefan hat sich längst > woanders herumgegoogelt! ;-) Wollt ihr wirklich alle Anfänger auf diese > Art verscheuchen? Die Methodik finde ich nicht gut. > Und der böse Kasten-Sektierer ;-) Naja, er scheint aber grosses Wissen > zu haben. Netter wäre gewesen, ihn mal zu fragen wo er her ist. Vielleicht ist jemand ja in der Nähe und kann ihm mal auf die Sprünge helfen.
Future schrieb: > Andreas H. schrieb: >> Jeder der erst mal für €10-20 mit 8-Bit anfängt wird zu gegebener Zeit >> auch 32-Bit machen, wenn er es braucht. > Ein AVR braucht mehr finazielle Zuwendung. Erst recht als Anfänger, wenn > es "out fo the box" sein soll. Ja - hast recht... Wenn man nichts verbilligt bekommt rechne mal mit 40 Euro für eine AVR Erstausstattung. Das ist ja ein Riesen Unterschied. >> >> Aber dann hat er den 8-Bitter schon richtig "ausgeknautscht" und wird >> den 32-Bitter vermutlich wesentlich besser in den Griff kriegen > > Und alle müssen mit einem Nissan Micra als erstes Auto anfangen. Wenn > der "ausgeknautscht" ist und nicht mehr reicht, darf man vorsichtig nach > einem Golf fragen. :-((( Nee - Das sind ja alles Fahrzeuge aus der Gruppe der "Personenkraftwagen" Aber bevor man den KFZ Führerschein macht empfiehlt es sich doch zumindest eine Zeitlang als Fahrradfahrer am Strassenverkehr teilgenommen zu haben. Und bevor du zur CE Prüfung zugelassen wirst erwartet man auch das du bereits eine Fahrerlaubniss Klasse B besitzt. Und es war zumindest lange Zeit so das man bevor man "jedes" Motorrad bewegen durfte erst mal ein paar Jahre auf gedrosselten MAschinen Erfahrung sammeln musste. Ach Ja: Zur Krönung ist es ja noch so das wenn du auf einem Auto mit hohem "Assistenzgrad", wo dir komplette HAndlungen während der Fahrt abgenommen werden, die Fahrprüfung machst, du einen Sperrvermerkt in die FE eingetragen bekommst das du Fahrzeuge ohne diese Funktion ebend NICHT fahren darfst. Klassisches Beispiel das Jedermann betreffen könnte ist da die Prüfung mit Automatikgetriebe. Diese Sperrvermerke hat man ganz schnell eingeführt nach dem die Automatikfahrzeuge bezahlbar wurden und viele Fahrschulen als "Luxus" Anboten darauf zu lernen um schneller Prüfungsfit zu sein... Im Ergebniss haben diese Automatikfahrschüler dann mit Knüppelschaltung plötzlich riesen Probleme verursacht... Jemand der aber die Basics gelernt hat, also die Knüppelschaltung beherrscht, den traut der Gesetzgeber ohne vorbehalte zu alle Schaltungsvarianten (Manuell, Halbautomatik und Automatik) gleichermaßen zu fahren. Deshalb musst du Fahrschulen mit Automatikfahrzeugen heute wieder echt suchen. Und Fahrschulen die neben ein paar ergänzenden Schnupperfahrten mit dem als Fahrschulwagen angemeldetem Privatfahrzeug des Fahrschulbesitzers auf Wunsch der Automatikfahrzeugbesitzenden Eltern auch noch tatsächlich Prüfungen auf diesen Fahrzeugen abnehmen lassen sind wohl die absolute Ausnahme. (Weitere Beispiele dieser Art betreffen zur Zeit wohl nur Personen mit Körperbehinderung - aber mal sehen was an Assistenzsystemen noch so kommen wird...) Also der Strassenverkehr ist für dein Argument ein ganz schlechtes Beispiel!!! Da verlierst du jeden Vergleich weil gerade da gilt das man klein Anfangen sollte. Aber hier ging es ja nicht um den Strassenverkehr sondern um die Architektur zum Einstieg. Und auch wenn man die tatsächliche Komplexität jetzt mal aussen vor lässt und wir alle wirklich annehmen würden das der SOLIDE Einstieg auf den genannten 32Bit systemen wirklich so einfach wie auf dem AVR oder PIC ist, dann bleiben die meiner Meinung nach immer noch die schlechtere Wahl, weil die bei den beiden für einen Einsteiger WICHTIGSTEN Argumenten trotzdem noch hinten liegen. Verfügbarkeit von Informationen & Tutorials gepaart mit weiter Verbreitung in den Foren bei Fragen - Ausserdem als zweites Argument die Verfügbarkeit von µC und Tools für den Gelegenheitsbastler. Nun praktisch JEDER Elektronikshop - auch die welche es noch mit echter Ladentheke gibt, hat zumindest ein paar AVR und PIC in DIL im Bestand. Der Versandhandel eine riesen Latte an bausteinen. Für die STM & Co. wird es bei den Hobbytauglichen Versendern zwar auch immer mehr, aber keinesfalls in der Vielfalt. Aber du kannst weiterhin gerne bei deiner Meinung bleiben, ich bleibe bei meiner. Gruß Carsten
:
Bearbeitet durch User
Future schrieb: > Warum traust du anderen nix zu? In ein paar Jahren suchst du hinter den > AVRs genauso hinterher wie heute bei den 68k. Alles zu seiner Zeit! Und > jetzt ist die Zeit für 32 Bit, auch für Anfänger. Das hat nichts mit Zutrauen zu tun, sondern einfach mit der Frage wie am effektivsten ein solides Grundlagenwissen erwirbt. Und da gilt für den Anfang nun einmal "Je Einfacher um so besser". Da es mit einem vernünftigen Grundlagenwissen ein leichtes ist zwischen den Controllerfamilien hin und her zu springen "wie ein junges Kitzlein" sind damit auch alle weiteren Fragen zur Zukunft einfach obsolet. Wenn ich in Zukunft mehr Leistung brauche als jetzt nehme ich einfach etwas mit mehr Leistung - Und zwar genau DIE FAMILIE die DANN für mich am besten geeignet ist. Die es aber jetzt vielleicht noch gar nicht gibt. Sorgen um darum ob ihre Entscheidung auch in fünf Jahren noch richtig ist müssen sich nur die Dumpfbacken die heute mit den "tollen Libs" lediglich Copy& Paste spielen, sich ganz dolle freuen das es nicht nur blinkt sondern auch Töne zu den Bildchen aufm TFT herauskommen, aber von den dahinterliegenden Funktionen in Wirklichkeit nichts verstanden haben. Aber in den Foren einen auf Dicke Hose machen wie tolle Fortschrittlich die doch sind. Ob der AVR also in fünf JAhren so selten sein wird wie die 68er heute (was ich sehr stark anzweifeln würde) spielt also heute gar keine Rolle bei der Einstiegsfrage. Es zählt nur was JETZT in Hobbyistenkreisen aktuell ist -und das sind nun einmal ganz klar PIC und AVR. Gruß Carsten
Andreas H. schrieb: > Antimedial schrieb: >> Schade, ihr habt beide nicht begriffen, was ich damit sagen wollte. > Keiner versteht Dich ? Du Armer ;-) Ich denke ihr versteht mich schon ganz gut. Das könnt ihr aber nicht zugeben, denn dann könntet ihr nicht ständig Eure falschen Argumente wiederholen. Andreas H. schrieb: >> Man kann Komplexität verbergen! > Aber will man das ? > Du programmierst doch einen embedded uP nicht aus Jux und Tollerei. Das > Ding hat eine Aufgabe. Und die ist meist nicht "Schreib 'Hello world' > auf das TFT oder "lass mal die LED blinken". Natürlich will man das! Gerade das TFT ist doch das perfekte Beispiel. Dort programmiert man ja nicht die Pixelmatrix direkt, sondern verwendet üblicherweise einen Controller. Und meistens nimmt man dann sogar einen fertigen Treiber und ein fertiges Grafik-Toolkit. Ohne Komplexität auf irgendeiner Ebene zu verbergen funktioniert heutzutage gar nichts mehr. Die Frage ist nur, auf welcher Ebene packt man an. Beim AVR gehen die meisten Anfänger schon lange nicht mehr auf Registerebene; die meisten Einsteiger fangen nämlich inzwischen mit dem Arduino an. Und ehrlich gesagt würde es mich fast wundern, wenn es nicht schon die ersten Ansätze gibt, die Arduino-Lib auf STM32 zu portieren. Spätestens dann spielt es keine Rolle mehr, mit welcher Plattform man anfängt. Andreas H. schrieb: > Aber was macht der arme STM32 User in dieser Situation ? Vielleicht doch > mal auf Registerebene (Bäh), mit ASM (Pfui) die typischen 1-2% > high-criticals per Hand nachoptimieren ? Assembler nützt gar nichts. Die Registerebene ist doch genau das, was ihr beim AVR vorschlagt. Und beim STM32 ist das jetzt plötzlich "Bäh"? Merkwürdig.
Blende22-Mint schrieb: > Wollt ihr wirklich alle Anfänger auf diese Art verscheuchen? Ja. Ist humaner als sie frustriert vor ihrem 32-Bit System versauern zu lassen > Die Methodik finde ich nicht gut. (Dafür gabs sogar mal einen Punkt von mir ;-) Ich auch nicht. Andererseits haben wir ja schon viel diskutiert und (hoffentlich) auch so, das ein Anfänger sich selber ein Bild machen kann. Wie er sich entscheidet will ihm sowieso keiner vorschreiben. Eine Fehlentscheidung kostet aber nur ~€20 und er merkt schon, wenns nicht gut klappt. Aber dann kennt er die prinzipiellen Alternativen und unterschiedlichen Ansichten der Leute, die das schon (mehr oder weniger) durch haben. Darum finde ich es auch toll wenn hier Leute posten, die auch gerade erst angefangen haben. Schlimmer wäre es, nur die "EINZIG WAHRE CPU, juhu" (tm) hochzujubeln und so zu tun als ob damit alles geht. Grüße Andreas
Joachim Drechsel schrieb: > Netter wäre gewesen, ihn mal zu fragen wo er her ist. Vielleicht > ist jemand ja in der Nähe und kann ihm mal auf die Sprünge helfen. Wäre das nicht etwas verfrüht ? Er hat ja vermutlich bis jetzt weder Teile noch ein Problem (Ausser uns ;-) Grüße Andreas
Andreas H. schrieb: > Schlimmer wäre es, nur die "EINZIG WAHRE CPU, juhu" (tm) hochzujubeln > und so zu tun als ob damit alles geht. Aber das treibst du doch hier seit Tagen. :-((( Andreas H. schrieb: > Er hat ja vermutlich bis jetzt weder > Teile noch ein Problem So ein Discovery Board oder ein Launchpad passt in die Handytasche. ;-) Hier wird es auf den Punkt gebracht: Antimedial schrieb: > Um es noch einmal klarzustellen: Ich will hier keinem vom AVR zum > Einstieg abraten, ich bin nur dagegen, dass man 32-Bit-µC von vornerein > als zu komplex abtut. Bitte wieder 3mal lesen damit es sitzt. ;-)))
Carsten Sch. schrieb: > Wenn man nichts verbilligt bekommt rechne mal mit 40 Euro für eine AVR > Erstausstattung. Das ist ja ein Riesen Unterschied. Verschwender ;-) Ansonsten bin ich, wie meistens, Deiner Meinung :-D Antimedial schrieb: > Beim AVR gehen die meisten Anfänger schon lange nicht mehr auf > Registerebene; die meisten Einsteiger fangen nämlich inzwischen mit dem > Arduino an. Und dann, wenn es nicht mehr reicht und sie schon etwas mehr Vertrauen in ihre Fähigkeiten haben, schauen sie mal, was sich hinter den dicken Arduino-Libs verbirgt und lernen auch wie der (relativ übersichtliche) uP funktioniert. Ja, finde ich völlig ok. Jeder kann sich seinen Lernfortschritt praktisch selber vorgeben ohne plötzlich erst mal rauskriegen zu müssen, was eigentlich "vectorised interrupt tables" sind, die auch noch durch die Gegend geschoben werden. > Assembler nützt gar nichts. Die Registerebene ist doch genau das, was > ihr beim AVR vorschlagt. Und beim STM32 ist das jetzt plötzlich "Bäh"? > Merkwürdig. Wenn Du den uP kennst, dann schreckt Dich ASM ja nicht wirklich. Das "Bäh" habe ich eher den Leuten "untergeschoben", die sowas vorher noch nie gemacht haben und dann auf Deinem M3 damit anfangen sollen. Grüße Andreas
+20 € für ein STM32F4DISCOVERY (Debugger ist schon dabei) und dann kann man bei beiden (AVR/STM32) mal mit einem BlinkLED sich versuchen und da merkt man schnell was einem besser gefällt. (ATMEL Studio/Coocox)
Andreas H. schrieb: > Und dann, wenn es nicht mehr reicht und sie schon etwas mehr Vertrauen > in ihre Fähigkeiten haben, schauen sie mal, was sich hinter den dicken > Arduino-Libs verbirgt und lernen auch wie der (relativ übersichtliche) > uP funktioniert. Eben, und das gleiche funktioniert wunderbar auf einem STM32 mit den Peripheral Libs. Andreas H. schrieb: > Wenn Du den uP kennst, dann schreckt Dich ASM ja nicht wirklich. Das > "Bäh" habe ich eher den Leuten "untergeschoben", die sowas vorher noch > nie gemacht haben und dann auf Deinem M3 damit anfangen sollen. Sie sollen ja eben nicht mit Assembler anfangen. Immer schön alle Argumente so lang rum drehen, bis sie passen, nicht wahr?
Andreas H. schrieb: > Blende22-Mint schrieb: >> Wollt ihr wirklich alle Anfänger auf diese Art verscheuchen? > > Ja. Ist humaner als sie frustriert vor ihrem 32-Bit System versauern zu > lassen > >> Die Methodik finde ich nicht gut. > (Dafür gabs sogar mal einen Punkt von mir ;-) > > Ich auch nicht. > > Andererseits haben wir ja schon viel diskutiert und (hoffentlich) auch > so, das ein Anfänger sich selber ein Bild machen kann. Mit Verlaub gesagt, habt Ihr das ganz sicher nicht getan. Habt ihr jetzt einen kompletten Sockenschuß? Da komuniziert ein TO mal halbwegs vernünftig seine Bedürfnisse und was macht ihr daraus? Bis zu diesem Punkt habe ich ja nicht mehr erwartet, aber man soll doch dieses Abdriften noch bitte nicht noch glorifizieren. Ich werde hier sicherlich nicht mehr versuchen etwas beizutragen. Und was ist eigentlich euer Problem? Das Thema ist tot!? Toll, jetzt pinkeln wir nocheinmal auf das Grab!? Das einzige sinnvolle was ihr hier noch leisten könnt, ist eine Abstimmung bei Beitrag "Wahl des Troll-Themas 2013" . Fertich! Nachtrag: Es ist ja nicht so, dass schon einige(!) Leute freundlich und dezent darauf hingewiesen haben...
:
Bearbeitet durch User
Future schrieb: > > Aber das treibst du doch hier seit Tagen. :-((( > Nö. Eigentlich habe ich einem Anfänger nur eine (in meinen Augen) einfache Einstiegsmöglichkeit genannt. > > Hier wird es auf den Punkt gebracht: > Antimedial schrieb: >> Um es noch einmal klarzustellen: Ich will hier keinem vom AVR zum >> Einstieg abraten, ich bin nur dagegen, dass man 32-Bit-µC von vornerein >> als zu komplex abtut. Und das sehe ich eben völlig anders. INSBESONDERE für Anfänger. Das 32-Bitter eine tolle Sache sind und man die auch super benutzen kann will ja auch garnicht bestreiten. Aber doch erst dann, wenn man sie auch handhaben kann. Und zwar (wie immer) wenn etwas schief geht. Es ist doch nichts schlimmer als wenn jemand ein Projekt in die Ecke schmeisst, weil er es, selbst mit Hilfe, nicht hinbekommt. Gerade am Anfang sind doch auch noch so kleine Schritte enorm schwierig und kompliziert. Oft ist ja schon das Aufsetzen der Umgebung ein Problem. Je komplexer ein System, desto mehr potentielle Fehlermöglichkeiten hat es. Und ich habe es einfach zu oft erlebt, das man sich (nicht nur) als Anfänger an völlig trivialen Sachen aufrauchen kann. Bei den heute "üblichen Verdächtigen" (also PIC & AVR) kann das Forum oft noch helfen, weil da Leute sitzen, die mit den Dingern genug Erfahrung haben. Es gibt tonnenweise gute Tutorials und Beispielcode. Und die kleinen CPUs sind noch extrem überschaubar, auch wenn man mal einen vermeintlich unmöglichen Fehler suchen muss, der spätestens dann auftritt wenn man mutig das erste mal mit zwei (!) IRQs arbeitet im selbstgebastelten Programm arbeitet. Dann ist man ganz schnell auf ASM Ebene und schaut sich an, was im Prozessor eigentlich passiert. Wegen meiner seht das alles als überholte Technik von gestern an aber für Anfänger ist es mehr als kompliziert. Als Anfänger glauben sie natürlich den "Experten". Und wenn die alle erzählen, dass es mit 32 Bit ja soo einfach ist, dann probieren sie es auch, wollen natürlich auch ganz schnell "so tolle Sachen" machen und sind dann schnell überfordert und danach extrem frustriert, wenn auch nur irgendwas ein bisschen schiefgeht. Die Leute wollen es doch lernen. Also gib ihnen doch wenigstens eine faire Chance. Und darum bin ich so am "rummeckern". Grüße Andreas
Hi >Immer schön alle Argumente so lang rum drehen, bis sie passen, nicht >wahr? Mal nachgeschaut: Im Dezember gab es, wenn ich mich nicht verzählt habe, 9 Anfragen zu ARM die nicht beantwortet wurden, bei AVR sieben. Allerdings bei etwa der dreifachen Anzahl Fragen zu AVR. Macht ein Verhältnis 7:27 nicht beantwortenter Fragen zu Gunsten AVR. Bei den restlichen Treads sind ganz andere unterwegs die helfen können als die zwei ARM-Protagonisten hier. MfG Spess
Andreas H. schrieb: > Nö. Eigentlich habe ich einem Anfänger nur eine (in meinen Augen) > einfache Einstiegsmöglichkeit genannt. Nein, du willst ihm (d)eine Einstiegsmöglichkeit diktieren! spess53 schrieb: > als die zwei ARM-Protagonisten Auch du solltest mehrfach lesen, damit es sackt: Future schrieb: > Hier wird es auf den Punkt gebracht: > Antimedial schrieb: >> Um es noch einmal klarzustellen: Ich will hier keinem vom AVR zum >> Einstieg abraten, ich bin nur dagegen, dass man 32-Bit-µC von vornerein >> als zu komplex abtut. > Bitte wieder 3mal lesen damit es sitzt. ;-)))
Also um dem mal einen Rahmen zu geben. Ich benutze im Moment bevorzugt den Tiny10, Tiny13 und Mega328 Nur mal ein schönes Beispiel was so ein Tiny13 kann: http://www.youtube.com/watch?v=BDuH56TEc1Q
Klaus I. schrieb: > > Habt ihr jetzt einen kompletten Sockenschuß? Da komuniziert ein TO mal > halbwegs vernünftig seine Bedürfnisse und was macht ihr daraus? > Hier "zanken" sich zwei Fraktionen darüber, ob es für Anfänger sinnvoller ist mit 8-Bit oder 32-Bit Prozessoren anzufangen. Und ? > Bis zu diesem Punkt habe ich ja nicht mehr erwartet, aber man soll doch > dieses Abdriften noch bitte nicht noch glorifizieren. > Welches Abdriften ? Der TO fragte womit er einsteigen sollte und zwei Hauptgruppen mit sehr unterschiedlichen Meinungen haben ihm geantwortet. Daraus hat sich eine (zugegebenermassen) hitzige aber (finde ich zumindest) auch witzige und interessante Diskussion entwickelt. Ich kannte z.B. den oben erwähnten LPC800 noch garnicht und nebenbei gabs auch mal einen kleinen Ausflug zum Thema "Hardwaredebugger: Sinn & Anwendung" > Das Thema ist tot!? Toll, jetzt pinkeln wir nocheinmal auf das Grab!? Für einen "toten Thread" erzeugt er aber noch interessante Seiteneffekte: spess53 schrieb: > Mal nachgeschaut: Im Dezember gab es, wenn ich mich nicht verzählt habe, > 9 Anfragen zu ARM die nicht beantwortet wurden, bei AVR sieben. > Allerdings bei etwa der dreifachen Anzahl Fragen zu AVR. Macht ein > Verhältnis 7:27 nicht beantwortenter Fragen zu Gunsten AVR. Klaus I. schrieb: > > Das einzige sinnvolle was ihr hier noch leisten könnt, ist eine > Abstimmung bei Beitrag "Wahl des Troll-Themas 2013" DAS ist für Dich ein Troll-Thread ? Ich dachte immer, da beschimpfen & provizoeren sich nur Leute, die sich eigentlich gegenseitig für Idi*** halten. Also ich halte weder Future noch Antimedial noch Carsten Sch. oder irgend einen der anderen Poster dafür. Im Gegenteil. Da ist viel KnowHow dabei. Ich für meinen Teil finde viele Inputs nachdenkenswert und tue das auch. Das wir uns hier auch gelegentlich mal "pieksen" finde ich persönlich auch nicht schlimm. Ein bischen Spas muss ja auch mal sein ;-) Das es teilweise etwas vorsichtig "um die Ecke" formuliert und dadurch etwas "länglicher" ist, ist doch logisch. Viel Wissen kommt doch auch von Projekten, die auf Arbeit entstanden sind. Entschuldige, dass man da nicht mal eben das exakte Beispiel auf den Tisch haut und sich danach die Kündigung wegen Verstoß gegen irgendwelche NDAs abholt. Grüße Andreas
spess53 schrieb: > Mal nachgeschaut: Im Dezember gab es, wenn ich mich nicht verzählt habe, > 9 Anfragen zu ARM die nicht beantwortet wurden, bei AVR sieben. > Allerdings bei etwa der dreifachen Anzahl Fragen zu AVR. Macht ein > Verhältnis 7:27 nicht beantwortenter Fragen zu Gunsten AVR. Wow, da hast Du Dir ja viel Arbeit gemacht. Vielen Dank :-) Ich muss zugeben, dass ich es mir nicht so krass vorgestellt hatte. Grüße Andreas
Future schrieb: > Andreas H. schrieb: >> Nö. Eigentlich habe ich einem Anfänger nur eine (in meinen Augen) >> einfache Einstiegsmöglichkeit genannt. > > Nein, du willst ihm (d)eine Einstiegsmöglichkeit diktieren! Und Du willst stellst einen Lehrling am ersten Tag an die Drehbank statt ihm erst mal feilen beizubringen. Ich will einen Anfänger nur nicht ins "offene Messer" rennen lassen. Ich habe das in den letzen 20 Jahren schon so oft live miterlebt und auch oft mitgeholfen, die Sachen noch zu kitten. Und 32-Bitter können schon ziemlich verzwickte Fehlerbilder haben, die ohne entsprechendes Equip kaum noch zu finden sind. Grüße Andreas P.S: Nur für die Akten: Ich rate Deine Beiträge nicht runter und habe da auch wenig Verständnis für. (Nur weil uns hier ja schon trolling vorgeworfen wird ;-) A.
Wisst ihr, ich lerne das ja auch noch und habe leider nicht immer so viel Zeit wie ich gern hätte. Das nächste halbe Jahr sogar gar keine Zeit, weil ich da jeden Abend was anderes lernen muss und bis in den Mai hinein, bis die Prüfung rum ist. Aber mein Ziel ist es Systeme zu bauen, die mit mehreren mehr oder weniger autonomen, kleinen Mikrocontrollern arbeiten. In meiner beruflichen Praxis habe ich mit vielen verschiedenen Steuerungen zu tun und ich will vielleicht mal ein ganz anderes Konzept erarbeiten. Dabei wird es eher auf die Programmierung und das Zusammenspiel der einzelnen µC's ankommen, als auf die Geschwindigkeit und viele Pins. Ich finde auch Hardware viel besser die einfach nur gut funktioniert, statt irgendwas auf einem Display anzuzeigen. Ich bin sogar der festen Überzeugung, dass es mehr in diese Richtung gehen wird. Sicher nicht so klein wie ich das machen will, aber die Tendenz wird da hin gehen. Große Reiche sind an der schlechten Kontrollierbarkeit zerbrochen und ähnlich wird es in der digitalen Welt auch werden. Da kommt es auf geschickte Ausnutzung von kleinen, aber zahlreichen Ressourcen an.
cyblord ---- schrieb: > C - Industriestandard. Nutzen die wirklich coolen Jungs die was drauf > haben (z.B. ich) Ui, da hat Mutti wohl beim Mittagstisch dem Sohnemann wieder ein Lob verteilt :3
F. Fo schrieb: > > Nur mal ein schönes Beispiel was so ein Tiny13 kann: > Youtube-Video "Bicycle Helmet with ATTiny13 controller" Das ist ja ein geniales Video. Extrem sehenswert :-) Beim "Stop" wird aber nur die Amplitude ausgewertet oder ist das echte Voice detection ? Ich traue dem ATTiny13 ja viel zu aber das würde mich wirklich überraschen. > > Also um dem mal einen Rahmen zu geben. > Ich benutze im Moment bevorzugt den Tiny10, Tiny13 und Mega328 Nur mal aus Neugier: Warum nimmst Du keine ATTiny45/85 ? Grüße Andreas
F. Fo schrieb: > Also um dem mal einen Rahmen zu geben. > Ich benutze im Moment bevorzugt den Tiny10, Tiny13 und Mega328 Und wie gehört das zum Thema? Was meinst du, wieviele verschiedene Controller es gibt. ;-) Andreas H. schrieb: > Hier "zanken" sich Du nimmst das persönlich. Daher dein Ehrgeiz. :-((( Mich würde interessieren, was sich der TO untern Baum gelegt hat. Klaus I. schrieb: > Das einzige sinnvolle was ihr hier noch leisten könnt, ist eine > Abstimmung bei Beitrag "Wahl des Troll-Themas 2013" Stimmt! http://www.youtube.com/watch?v=tAg-Il-nnGY
F. Fo schrieb: > Aber mein Ziel ist es Systeme zu bauen, die mit mehreren mehr oder > weniger autonomen, kleinen Mikrocontrollern arbeiten. Das ist ein total faszinierendes Thema. Google mal nach "swarm intelligence" oder "Kollektive Intelligenz" > In meiner beruflichen Praxis habe ich mit vielen verschiedenen > Steuerungen zu tun und ich will vielleicht mal ein ganz anderes Konzept > erarbeiten. > Dabei wird es eher auf die Programmierung und das Zusammenspiel der > einzelnen µC's ankommen, als auf die Geschwindigkeit und viele Pins. > Ich finde auch Hardware viel besser die einfach nur gut funktioniert, > statt irgendwas auf einem Display anzuzeigen. > Ich bin sogar der festen Überzeugung, dass es mehr in diese Richtung > gehen wird. Sicher nicht so klein wie ich das machen will, aber die > Tendenz wird da hin gehen. Ja, ich sehe da auch einiges an Potential. Zum Beispiel kann man die Ausfallsicherheit damit massiv erhöhen oder auch Kommunikationskanäle zuverlässiger machen. > Da kommt es auf geschickte Ausnutzung von kleinen, aber zahlreichen > Ressourcen an. Jup. Insbesondere müssen die Einheiten nicht mal besnders "clever" sein, wenn man den Swarm-Intelligence Artikeln im Netz so glaubt. Aber das wird jetz leider doch extrem off-topic, oder ? Wenn Du loslegst wäre ich aber sehr gespannt, wie das klappt. Am besten einen Thread dazu aufmachen und bitte PM an mich (ich übersehe immer soviele Threads :/ ) Grüße Andreas
Andreas H. schrieb: > Nur mal aus Neugier: Warum nimmst Du keine ATTiny45/85 ? Teuer und der Speicher reichte bis jetzt für die wenigen Sachen die die Dinger machen müssen. Nur ein Beispiel noch. Für meinen 190ziger habe ich ein Tester gebaut - zuvor analog, aber die Led war dann immer an (hätte auch einen 555 nehmen können) - da hab ich nur den ISR(INT0_vect) gebraucht. Wozu also den größeren nehmen? Wenn ich soweit bin (ich lerne das ja noch!), dass ich da nichts mehr raus quetschen kann, dann fange ich mit größeren µC's an oder wenn es die Aufgabenstellung erfordert.
:
Bearbeitet durch User
Future schrieb: > Und wie gehört das zum Thema? Was meinst du, wieviele verschiedene > Controller es gibt. ;-) Passt doch gut ins Bild. 8-Bit, weil genug Leistung und gut handhabbar :-) Vielleicht sollten wir mal eine Umfrage machen, wieviele Leute wirklich von 8-Bit PIC/AVR auf Cortexe umgestiegen sind. Anscheinend sind die Hürden ja doch höher als Du immer vermutest. Future schrieb: > Andreas H. schrieb: >> Hier "zanken" sich > > Du nimmst das persönlich. Daher dein Ehrgeiz. :-((( Nene, keine Sorge. Ich nehm das nicht persönlich und mein Ehrgeiz ist momentan ganz woanders. Darum kommen meine Posts ja auch immer on-block. Da hat das andere Thema gerade Pause :-) > > Mich würde interessieren, was sich der TO untern Baum gelegt hat. €1 auf Arduino :-) > > Klaus I. schrieb: >> Das einzige sinnvolle was ihr hier noch leisten könnt, ist eine >> Abstimmung bei Beitrag "Wahl des Troll-Themas 2013" > > Stimmt! Youtube-Video "Siblings (Jo, wir schaffen das!)" Hihi, auch nicht schlecht. Grüße Andreas
F. Fo schrieb: > Andreas H. schrieb: >> Nur mal aus Neugier: Warum nimmst Du keine ATTiny45/85 ? > > Teuer Der T85 kostet 1,15 bei reichelt. Der tiny13 0,99. Also komm schon ;-) Ich würde auch keine 13er mehr nehmen für neue Projekte. Der 85 bietet einfach einiges mehr und hat keine Nachteile zum 13er. Dafür 8x mehr Flash und 8x mehr RAM! Wie kann man da zum t13 raten? gruß cyblord
:
Bearbeitet durch User
F. Fo schrieb: > Teuer und der Speicher reichte bis jetzt für die wenigen Sachen die die > Dinger machen müssen. Ups. Ich hatte Die immer preislich etwa gleich im Hinterkopf. Aber der ATTiny hat so extrem wenig RAM/ROM. Ich neige da in der Zwischenzeit leider öfter zur Verschwendung :/ > Nur ein Beispiel noch. Für meinen 190ziger habe ich ein Tester gebaut - > zuvor analog, aber die Led war dann immer an (hätte auch einen 555 > nehmen können) - > da hab ich nur den ISR(INT0_vect) gebraucht. Was machst Du da, wenn ich fragen darf ? Motor ist immer so übel verdreckt (also elektrisch natürlich). Grüße Andreas
cyblord ---- schrieb: > F. Fo schrieb: >> Andreas H. schrieb: >>> Nur mal aus Neugier: Warum nimmst Du keine ATTiny45/85 ? >> >> Teuer > > Der T85 kostet 1,15 bei reichelt. Der tiny13 0,99. Also komm schon ;-) > > Ich würde auch keine 13er mehr nehmen für neue Projekte. Der 85 bietet > einfach einiges mehr und hat keine Nachteile zum 13er. > > Dafür 8x mehr Flash und 8x mehr RAM! Wie kann man da zum t13 raten? > > gruß cyblord Hallo mein lieber Cyblord! Noch mal am Rande und zu dir persönlich: Du hattest so recht schnell zu C zu finden. Das ist ja so geil. Mal eben das Programm auf einen anderen µC, mit kleinen Anpassungen und schon läuft es da auch. Der Tiny13 kostet beim Markus 60 cent, der T85 90 cent und der Tiny10 nur 50 cent. Aber es geht gar nicht darum was die kosten. Ich will erstmal an Grenzen stoßen und dann will ich sehen, ob ich diese Grenzen noch verschieben kann. Das soll alles dem Lernen dienen. Weißt du, vor zwei Jahren habe ich noch Geräte weggeworfen, wenn sie kaputt waren oder nicht den Anforderungen entsprachen, heute fange ich an sie immer häufiger zu reparieren oder auf meine Bedürfnisse anzupassen. Ich für mich und ganz ohne Hilfe vor Ort, bin schon recht weit gekommen, in der für mich relativ kurzen Zeit. Gestern noch, da habe ich den HDMI Umschalter mit nem Phototransistor fernbedienbar gemacht; eben zwischendurch, weil mich das Teil nervte. Vor zwei Jahren hätte ich den Phototransistor für ne Led gehalten. und schon gar nicht gewusst was und wie ich da was mit machen kann.
F. Fo schrieb: > Noch mal am Rande und zu dir persönlich: Du hattest so recht schnell zu > C zu finden. Das ist ja so geil. Mal eben das Programm auf einen anderen > µC, mit kleinen Anpassungen und schon läuft es da auch. Freut mich sehr dass dir C zusagt. > Aber es geht gar nicht darum was die kosten. Ich will erstmal an Grenzen > stoßen und dann will ich sehen, ob ich diese Grenzen noch verschieben > kann. > Das soll alles dem Lernen dienen. Ja sicher ok, aber schau doch mal ins DB was der T85 so alles unter der Haube hat. Das sind oft kleine unscheinbare Dinge, wie z.B. der diff. ADC mit 20x Gain, oder die PCINTs. Mehr Platz ist einfach durch nichts zu ersetzen, außer durch noch mehr Platz. Mit 1kb Flash würde ich aktuell bei keinem Projekt auskommen. Egal ob kleiner M-Link Sensor oder sonst was. Kommt halt drauf an was man macht. Aber mit dem T85 kann man einfach schon echt viel Programm unterbringen und so auch komplexere Dinge bauen ohne mit jedem Byte zu geizen. Und der Umstieg ist einfach, da der T85 Pinkompatibel zum T13 ist, und auch sonst das meiste einfach 1:1 übernommen werden kann. gruß cyblord
:
Bearbeitet durch User
cyblord ---- schrieb: > Aber mit dem T85 kann man einfach schon echt viel Programm unterbringen > und so auch komplexere Dinge bauen ohne mit jedem Byte zu geizen. > > Und der Umstieg ist einfach, da der T85 Pinkompatibel zum T13 ist, und > auch sonst das meiste einfach 1:1 übernommen werden kann. > > gruß cyblord Ja ich weiß, und wenn es knapp wird -keine Angst, hab beide hier- dann nehme ich den ganz sicher. Dass er sich außer im Platz unterscheidet, das wusste ich nicht. Aber noch ein Video was mit nem Tiny13 so geht: http://www.youtube.com/watch?v=EZfwxmSBr3s Ich finde das ganz beachtlich.
Andreas H. schrieb: > "swarm > intelligence" oder "Kollektive Intelligenz" Das brachte mich dazu einen jahrelangen Gedanken zu konkretisieren. ... aber bis dahin ist es noch ein langer Weg. Oft war ich mit meinen Ideen der Zeit voraus und ich glaube auch da bin ich ein wenig voraus, zumindest was die Grundidee angeht.
Echt krass, die Reaktionen hier, auf eine solche Fragestellung. Wer sich die Mühe macht hier zu lesen, wird wohl feststellen das es nicht die perfekte Auswahl für Anfänger gibt, sondern verschiedene Möglichkeiten. Mein erster Mikrocontroller war ein Arduino Board, man befolgt da ein paar Anweisungen in einem Tutorial und es blinkt. Es gab keinen wirklichen Anreiz etwas wirklich zu lernen. Man bekommt den Eindruck, dass man bei Bedarf nur das entsprechende Tutorial im Internet suchen müsse. Anders war es, als ich ohne das Arduino Board mich mit AVR Mikrokontrollern beschäftigte. Ich habe direkt mit Assembler angefangen, aber auch gleichzeitig immer geschaut wie es in C ausschaut. Also da hatte ich das Gefühl ich könne und müsse etwas lernen und das was man lernt sind elementare Grundlagen. Wenn man sie aber beherrscht muss man keine Tutorials mehr suchen sondern weiß wie man etwas realisieren kann. Dennoch haben Arduino Boards ihre Existenzberechtigung denke ich mir. Sonst gäbe es die riesige Arduino Community nicht. Die Leute nutzen es, spielen damit herum. Es macht viele auf die Welt der Mikrocontroller Entwicklung aufmerksam. 8 Bit oder 32 Bit? Klingt wie nach einer Frage ob C/C++ oder Java besser geeignet ist zum erlernen einer Programmiersprache, oder überhaupt welche die beste Programmiersprache sei. Über solche Fragestellungen kann man doch nur schmunzeln. Wenn für eine bestimmte Aufgabe ein 8 Bit ATtiny völlig ausreichend ist, werde ich kein 32 Bit Chip nutzen. Auch wenn man es als Hobby betreibt, kann es nicht schaden etwas wirtschaftlich zu denken. In der Produktentwicklung soll ein Chip nicht unnötig mehr Platz oder Strom verbrauchen und auch nicht unnötig zu viel kosten, man wählt einfach für die Anforderung den idealen Chip aus.
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.