Hallo, ich bin im dritten Semester und muss für ein Entwicklungsprojekt einen Mikrocontroller verwenden und weiß nicht welchen ich verwenden soll. Der betreuende Prof hat wenig Bock uns zu helfen und meint er hätte früher XC888 (8051) programmiert, wir wollen aber etwas moderneres benutzen und können nicht entscheiden ob wir einen AVR oder einen STM32 benutzen sollen. Ich habe Erfahrung mit HTML und Java Programmierung und will das vielleicht auch einfach mit Python oder Arduino programmieren wenn es geht. Könnt ihr mir helfen da einen Microcontroller auszusuchen? Vielen Dank für eure Antworten
B-anfänger schrieb: > für ein Entwicklungsprojekt Etwas genauer könnte es schon sein. Soll nur eine LED oder ein Motor bedient werden, oder geht es auch um USB und Web Anbindung?
Einen Toaster der den Toast möglichst perfekt gart mit thermischer Auswertung der Brotoberfläche.
Dafür ist ein AVR bestens geeignet und auch leichter verständlich. Die vielen Tutorials und Beispiele bieten einen schnellen Erfolg.
B-anfänger schrieb: > Hallo, > > ich bin im dritten Semester und muss für ein Entwicklungsprojekt einen > Mikrocontroller verwenden und weiß nicht welchen ich verwenden soll. Der Die STM32s decken ein deutlich größeren Leistungsbereich ab (STM32Lxxx .. STM32H7xxx).
AVRs sind trivial, einfach zu verwenden, haben weniger Leistung. Denk an die Zukunft: willst du mal in dem Bereich arbeiten, nimm den ARM. Willst du nur schnell fertig werden, tuts evtl irgendein arduino. Interessant zu wissen wäre, wie diese thermische auswertung geschehen soll? Vielleicht stellt der Sensor ja Anforderungen?
B-anfänger schrieb: > Der betreuende Prof hat wenig Bock uns zu helfen und meint er hätte früher > XC888 (8051) programmiert Wenn du deinem Prof gefallen willst, nimm einen ein Arduino-Nano-Board und programmiere Bare-Metal. Zu Beginn kannst du hier auch die Arduino-Beispiele und die Arduino IDE verwenden. Das ist auf jeden Fall der einfachste Einstieg. Wenn du sein Liebling werden willst, nimm einen 8051 und nutze den SDCC-Compiler. Wenn du auch HTML nutzen willst, nimm ein embedded Wlan-Modul ab ESP8266 oder ESP32, dann hast du den Webserver auch gleich erschlagen. Für die gibt es auch sehr viel Beispiele und Foren. Nimm auf jeden Fall etwas verbreitetes. Bei den STMs gibts zwar auch dolles Zeug, jedoch gibt es für den einzelnen Controller selten vergleichbare Mengen an Beispiel-Codes. Nimm also etwa in der Reihenfolge: nimm keine Exoten, nimm was du kennst, nimm wofür es große Communities gibt, nimm was deine Freunde kennen.
mts schrieb: > Die STM32s decken ein deutlich größeren Leistungsbereich ab (STM32Lxxx > .. STM32H7xxx). ??? Mit Atmel-Studio/Atmel-ICE geht der "Leistungsbereich" vom 8-poligen 8bit-Tiny bis zum 32bit Cortex-M4, da kannst Du, wenn die 8 bit nicht reichen, zu leistungsfähigeren Controllern (mega, xmega, arm) wechseln, ohne die IDE oder das ICE zu wechseln. Ausserdem bietet das ASF von Atmel gerade für Beginner gute Unterstützung. mfg Achim
Ich würde dir auch zu einem Arduino raten. Es ist einfach damit einzusteigen. Evtl. bekommst du noch Argumente wie, das ist veraltete Technologie. Das würde ich nicht auf die Goldwaage legen. Wenn der Prof. einen AVR akzeptiert ist es ok. Eine 1N4148 oder ein LM317 sind altersmäßig toter als tod und werden trotzdem noch verwendet. Sie haben sich einfach bewährt. Nicht alles was heute der letzte Schrei ist, muss auch morgen noch gut verfügbar sein. Dass ein Arduino in 5 Jahren zum Exoten gehört, glaube ich nicht.
B-anfänger schrieb: > Einen Toaster der den Toast möglichst perfekt gart mit thermischer > Auswertung der Brotoberfläche. Und ernsthaft? Ich meine, sowas braucht doch niemand?
Haha schrieb: > B-anfänger schrieb: >> Einen Toaster der den Toast möglichst perfekt gart mit thermischer >> Auswertung der Brotoberfläche. > > Und ernsthaft? Ich meine, sowas braucht doch niemand? Deine Meinung braucht auch niemand, und trotzdem belästigst Du uns damit. So what?
Die Entwicklung in ein Forum auszulagern, ist bestimmt nicht das erwünschte Verhalten. Ansonsten ist es es doch wohl völlig egal, was am Ende eingesetzt wird, solange es die Anforderungen erfüllt. Oder andersrum: Solange die Anforderungen nicht ausformuliert werden, ist die Entscheidung/Frage "Welcher µC?" völlig daneben. Übrigens, in meinem Toaster steckt ein Chip im SMD Tiny85 Design. Welche wirklich, KA.
B-anfänger schrieb: > Einen Toaster der den Toast möglichst perfekt gart mit thermischer > Auswertung der Brotoberfläche. Ist der Controller nicht erstmal egal? Brote toasten kann keiner von beiden. Es geht doch zuerst um die Auswerte-Elektronik. Das kann keiner der Controller von sich aus...
für ein Blinki Projekt? Ganz ernsthaft..verwende einen STM32(arm) Damit blinken die leds ganz erhLblich eleganter und farbkräftiger! Damit kannst Du wirklich für Eindruck sorgen! SCHERZ Nein, wenn Du in dem Bereich was studierst und auch privat damit dich weiter beschäftigen willst, verwende STM32, z.B. den STM32 Bluepill bei ebay für 2€ Du hast da gleich DAC, 12Bit ADc, viel Power, Ram etc.. Brauchst Du e nur für dieses Projekt und sonst nicht mehr groß.. Nimm einem Atmega32 bzw dessen aktuellen nachfolger, weil es da unendlich wie Doku im Netz gibt und sehr einfach und schnell zu programmieren ohne Spezielle Flash tools etc..einfach n ein PC Port einen Adapter basteln und gut oder fertig bei ebay für 2e kaufen
das mit dem Toaster lese ich jetzt gerade erst, es gilt aber das eben gesagte.. Willst Du weiter privat basteln verwende >STM32, brauchst Du es nur für solche Projekte verwende Atmega, in diesem Fall reicht es sogar noch keiner. Atmega 88 z.B.
Technisch gesehen sind beide Mikrocontroller gleich gut geeignet. Bei AVR sehe ich den Vorteil, dass sie leichter/schneller zu erlernen sind. Bei STM32 sehe ich den Vorteil, dass die Hardware zum Debuggen sehr viel billiger ist. Rechenleistung und Anzahl der Pins sind für deine Anwendung weitgehend irrelevant. Wenn du Zeit hast, würde ich Dir zum STM32 raten, und zwar einem "Nucelo 64 STM32F103RB". Denn da ist der Programmieradapter/Debugger schon dabei. Wenn du unter Zeitdruck stehst, dann greife lieber zum AVR, und zwar einem Arduino Nano compatible Board. Zum Programmieren solltest du allerdings nicht das Arduino Framework verwenden, sonder eine ausgewachsene Entwicklungsumgebung.
Eigentlich habt ihr alle nichts anderes getan, als mit vielen Worten meine 2 Sätze zu bestätigen. ;) Beitrag "Re: AVR oder STM32 für Entwicklungsprojekt"
B-anfänger schrieb: > ich bin im dritten Semester und muss für ein Entwicklungsprojekt einen > Mikrocontroller verwenden und weiß nicht welchen ich verwenden soll. Der > betreuende Prof hat wenig Bock uns zu helfen und meint er hätte früher > XC888 (8051) programmiert, wir wollen aber etwas moderneres benutzen und > können nicht entscheiden ob wir einen AVR oder einen STM32 benutzen > sollen. Eines vorab: Weder AVR noch STM32 sind die häufigsten µCs in der industriellen Praxis. Da müssstet ihr bei Renesas schauen. Das nur deshalb, weil die grauseligen STM32-Fanboys immer so penetrant Ihr Zeug in den Himmel loben. Im Prinzip ists aber reichlich wurscht, welchen ihr nehmt. Viel wichtiger als der µC ist, dass ihr mit den Datenblättern und der Entwicklungsumgebung klarkommt. Und die solltet ihr euch vorher unbedingt ansehen! Mein Rat wäre: Beides mal ausprobieren. Den AVR kann man auf einem Breadboard ausprobieren, für den STM32 könnt ihr euch ein Discovery-Board bestellen, das nur 10€ kostet. Kauft euch am Besten eines für einen F0, nicht den F4. Nehmt eutch midestens einen Tag pro µC, und programmiert ein LED-LAuflicht mit Timer oder dergleichen von Grund auf. Achtet darauf: Findet Ihr die Informationen im Datenblatt? Wie kommt ihr mit der IDE klar? Sind vorhandene Sourcen für euch verständlich? Meine Meinung(!): Ich persönlich mag AVRs nicht, weil man mit den billigen Tools nicht mal gescheit debuggen kann, und weil ich persönlich das Atmel-Studio nicht mag. Bei STM32 gefällt mir die Firmware(CUBE-MX, Peripheral-Lib) überhaupt nicht, dafür ist die Hardware wirklich anständig.
Ich kenne so ziemlich alle Plattformen und rate Dir, nicht mehr zu AVR zu greifen - zumindest nicht zu den von den ganzen Bastlern hier verwendeten. Zumindest mit den billigen Programmieradaptern läuft das so ab: - Code schreiben - compilieren - auf den Chip laden - schauen, ob es geht - zurück zum Anfang Bei besseren Systemen kannst Du dem Prozessor auf die Finger schauen, Register auslesen, Speicher anschauen, Anweisungen Schritt für Schritt ausführen usw. Ich finde das extrem nützlich. Auf anderen Architekturen wie ARM, MIPS, PIC, MSP430 ist das Standard, und die Programmieradapter dafür sind billig. Bei AVR können das nur die größeren mit 40 Pins und mehr richtig schön (JTAG). Die kleineren haben mittlerweise DebugWire und können das damit auch, aber nicht so schön. Sicher, notfalls kommt man ohne aus, aber ich finde es manchmal extrem praktisch. Ihr solltet Euch auch noch PIC24 und PIC32 anschauen. Die sind beide deutlich leistungsfähiger als AVR bei gleichem Preis, lassen sich sehr schön programmieren und debuggen, und ein PICKIT3-Nachkau kostet beim Chinesen irgendwie 20€ oder so. Plus: Es gibt auch Varianten im DIL-Gehäuse. Der Prozessor braucht nur 3.3V, 2*100nF, einmal 10uF Tantal oder Keramisch und einmal 10k von MCLR nach 3.3V. Damit läuft der los. Das bekommt Ihr in einer Stunde zusammen gelötet. Die anderen Architekturen gibts alle nur in SMD-Gehäusen, das ist dann nicht mehr ganz so einfach. OpenSource-Fetischisten werden jetzt einwerfen, dass die Compiler unfrei im Sinne der Open-Source-Bewegung und eingeschränkt sind. Ja, damit haben sie zwar recht, aber für Euch ist das egal. Ihr könnt Euch Entwicklungsumgebung, Compiler, Bibliotheken einfach so kostenlos runterladen und installieren. Es ist alles aus einer Hand, es passt alles zusammen, und die genannten Einschränkungen findet Ihr nicht, wenn Ihr nicht wisst, wo Ihr suchen sollt. fchk
Frank K. schrieb: > Ich kenne so ziemlich alle Plattformen und rate Dir, nicht mehr zu AVR > zu greifen - zumindest nicht zu den von den ganzen Bastlern hier > verwendeten. > > Zumindest mit den billigen Programmieradaptern läuft das so ab: > - Code schreiben > - compilieren > - auf den Chip laden > - schauen, ob es geht > - zurück zum Anfang > > Bei besseren Systemen kannst Du dem Prozessor auf die Finger schauen, > Register auslesen, Speicher anschauen, Anweisungen Schritt für Schritt > ausführen usw. Ich finde das extrem nützlich. > Bei AVR können das nur die größeren mit 40 Pins und mehr richtig > schön (JTAG). Die kleineren haben > mittlerweise DebugWire und können das damit auch, aber nicht so schön. Womit du gerade Dir selbst widersprochen hast. Richtig ist, dass man fast alle AVR Modelle debuggen kann, außer die der allerersten Generation (benutzt die überhaupt noch wer?). Richtig ist aber auch, da stimme ich Dir zu, dass das Debugging auf AVR teure Adapter und Geduld erfordert. Ich bin davon auch nicht begeistert. Andererseits verspüre ich nur selten den Bedarf zu debuggen. Ich komme mit dem Ausgeben von Logmeldungen besser klar, was unter anderem wohl auch daran liegen mag, dass ich im Beruf überwiegend anhand von Protokolldateien arbeiten muss und keinen Zugang zu den produktiven Maschinen habe.
jemand schrieb: > Meine Meinung(!): > Ich persönlich mag AVRs nicht, weil man mit den billigen Tools nicht mal > gescheit debuggen kann, und weil ich persönlich das Atmel-Studio nicht > mag. Ja, geht mir auch so, wobei man Atmel-Studio nicht verwenden muss. Das mit dem Debugg ist aber richtig blöd. > Bei STM32 gefällt mir die Firmware(CUBE-MX, Peripheral-Lib) überhaupt > nicht, dafür ist die Hardware wirklich anständig. HAL ist zum kotzen - ich nehme daher immer die normale CMSIS StdPeriphLib, die es zum Glück auch noch gibt.
Frank K. schrieb: > Bei besseren Systemen kannst Du dem Prozessor auf die Finger schauen, > Register auslesen, Speicher anschauen, Anweisungen Schritt für Schritt > ausführen usw. Ich finde das extrem nützlich. Diese Art zu debuggen wird gerne deutlich überbewertet! Zumindest, wenn man die Programme in einer Hochsprache schreibt. Oder es mit "lebhaften" Inputs zu tun hat.
Mampf F. schrieb: > HAL ist zum kotzen - ich nehme daher immer die normale CMSIS > StdPeriphLib, die es zum Glück auch noch gibt. Du bringst Begriffe durcheinander. Der CMSIS Core enthält die Definitionen der Register und eine sehr kleine Anzahl von Hilfsfunktionen für Funktionen des ARM Kerns. Der Umfang des CMSIS Core ist von ARM festgelegt, die konkrete Implementierung kommt aber vom Chiphersteller. Darauf aufbauend gibt es Erweiterungen von ARM, wie das CMSIS-RTOS. Cube HAL von ST basiert ebenfalls auf CMSIS. Die StdPeriphLib von ST basiert ebenfalls auf CMSIS, sie heisst deswegen aber nicht CMSIS StdPeriphLib sondern einfach nur StdPeriphLib.
Es ist ja wieder das übliche µC Roulette, die Frage habe ich in ähnlicher Form hier glaube ich schon mal gelesen :) Da erinnere ich dann auch gerne wieder an einen meiner Lieblinge, den zu wenig beachteten LPC824, ein Cortex-M0 mit 32 kB Flash und 8 kB RAM (das ist bei den AVR ja sehr sparsam vorhanden). Den SMD Käfer auf eine einfache passive Adapterplatine, einen 100 nF C zwischen die Stromversorgungspins und fertig ist das Evalboard. Programmieren über den eingebauten Bootloader mit USB-RS232 Adapter für 1€, C Quellen gibts bei GitHub oder ich als fauler Informatiker nehme sogar ein fertiges OS dafür. Interessant wäre für die Anwendung (soll es wirklich eine Toastersteuerung werden?) noch die nRF51/52, Cortex-M0/4 mit Bluetooth Hardware. Dann kann der Toaster den Toaststatus gleich an eine Smartphone App schicken. Oder mit einem ESP8266 per WLAN melden. Wenn noch eine Wirtschaftlichkeitsbetrachtung zum Projekt gehört sind die low cost µC für wenige ct vielleicht noch interessant, da geistern ja auch gerade einige hier durchs Forum.
mts schrieb: > Die STM32s decken ein deutlich größeren Leistungsbereich ab (STM32Lxxx > .. STM32H7xxx). Ich würde mir für den Garten nie einen Spaten kaufen, da ein richtiger Bagger viel leistungsfähiger ist :-( B-anfänger schrieb: > Könnt ihr mir helfen da einen Microcontroller auszusuchen? Nimm einen Arduino Uno mit steckbarem ATmega328. Damit siehst du am ehesten Land und kommst ohne Frust ans Ziel. Wenn Du Deinem Prof eine besondere Freude machen möchtest, könntest Du auch ein 8051-Derivat zum Beispiel von Silabs nehmen. Für genauere Angaben dazu gibt es hier andere Spezies. (Einer davon war ja ganz besonders penetrant, dennoch habe ich seinen Namen schon vergessen ;-)
m.n. schrieb: > Wenn Du Deinem Prof eine besondere Freude machen möchtest, könntest Du > auch ein 8051-Derivat zum Beispiel von Silabs nehmen. Haha, geile Aussage! Die strotzt nur so von Kritik! Love it! ?
Frank K. schrieb: > Bei besseren Systemen kannst Du dem Prozessor auf die Finger schauen, > Register auslesen, Speicher anschauen, Anweisungen Schritt für Schritt > ausführen usw. Ich finde das extrem nützlich. Dann hast du wirklich NIEMALS Echtzeitsysteme programmiert. Dabei hilft dir ein Debugger nämlich so gut wie garnicht. Bestenfalls kannst du damit die Stelle fangen, an der ein Fehler "sichtbar" wird. Aber das kann man auch mit einer blöden Debug-LED tun... Na gut, mit einem Debugger kannst du dann noch den Stack inspizieren, aber das war es auch schon fast, was er für dich tun kann. Wer glaubt, wirklich unbedingt einen Debugger für einen µC zu brauchen, ist definitiv Anfänger. Nö, komplexe Routinen oder gar Devices testet man im Simulator. Damit kann man nämlich repredozierbar die Stelle erreichen, an der der Fehler sichtbar wird. Und sich dann (in vielen Läufen der immer gleichen Ausgangssituation) zurückhangeln zu der Stelle, wo das eigentliche Problem steckt, was leider nur allzuoft viele Hunderttausend oder Millionen Takte vor dem Moment ist, an dem es offensichtlich wird...
c-hater schrieb: > Frank K. schrieb: > >> Bei besseren Systemen kannst Du dem Prozessor auf die Finger schauen, >> Register auslesen, Speicher anschauen, Anweisungen Schritt für Schritt >> ausführen usw. Ich finde das extrem nützlich. > > Dann hast du wirklich NIEMALS Echtzeitsysteme programmiert. Dabei > hilft dir ein Debugger nämlich so gut wie garnicht. Bestenfalls kannst > du damit die Stelle fangen, an der ein Fehler "sichtbar" wird. Das Problem hat man bei kleineren Dingen auch schon ... z.B. DS18B20, bei dem man die 1-wire Kommunikation nicht mehr im Single-Step-Modus debuggen kann. Da gehören auch WS2812 LEDs dazu mit ihrem affigen asynchronen Timing. > Na gut, mit einem Debugger kannst du dann noch den Stack inspizieren, > aber das war es auch schon fast, was er für dich tun kann. Ist das zu wenig? Breakpoints, Single-Step-Debugging, Variablen anschauen? Ist halt das, was ein Debugger kann ... Ahja und printf über z.B. SWD ist halt auch ultrapraktisch. > Wer glaubt, wirklich unbedingt einen Debugger für einen µC zu brauchen, > ist definitiv Anfänger. Mehr als eine Dekade hab ich µCs programmiert und musste mit LEDs debuggen - trotzdem wäre es für mich nun ein Ausschlusskriterium, für zukünftige Projekte einen µC verwenden, den ich nicht debuggen kann (oder der ein sauteures proprietäres Debugging-Equipment benötigt). (Einzige Ausnahme: Es reicht ein AVR locker aus und Cortex ARM wäre über das Ziel hinausgeschossen^^) Wirklich unbedingt braucht man einen Debugger nicht - ich würde aber darauf nicht mehr verzichten wollen. Und so µCs wie Cortex ARM sind ungleich komplexer als AVRs ... Da war ich an einigen Stellen froh, dass ich mit dem Debugger nachschauen konnte, weshalb er nicht das macht, was ich denke, was er machen sollte ;-) > Nö, komplexe Routinen oder gar Devices testet man im Simulator. Damit > kann man nämlich repredozierbar die Stelle erreichen, an der der Fehler > sichtbar wird. Komplexe Routinen teste ich in C auf dem PC und den Simulator hab ich noch niemals verwendet und noch niemals Bedarf gehabt, ihn zu verwenden. Anstatt über die Notwendigkeit einen Debugger zu verwenden, könnte man auch über die Notwendigkeit einen Simulator zu verwenden, diskutieren.
:
Bearbeitet durch User
Arduino Fanboy D. schrieb: > Frank K. schrieb: >> Bei besseren Systemen kannst Du dem Prozessor auf die Finger schauen, >> Register auslesen, Speicher anschauen, Anweisungen Schritt für Schritt >> ausführen usw. Ich finde das extrem nützlich. > > Diese Art zu debuggen wird gerne deutlich überbewertet! > Zumindest, wenn man die Programme in einer Hochsprache schreibt. > > Oder es mit "lebhaften" Inputs zu tun hat. Für mich ist es eine nützliche Ergänzung. Beispiel aus der vergangenen Woche: Ich nehme eine neue Leiterplatte in Betrieb, und irgendwo bekomme ich kein Signal. Ich halte den Prozessor an, lasse mir die IO-Port Register anzeigen, toggle per Mausklick das entsprechende Bits und schaue per Oszi, bis wohin meine Mausklicks ankommen. So habe ich ziemlich schnell eine fehlende Lötstelle gefunden. Ohne Debugger wäre das sicher aus gegangen, aber eben nicht so schnell. Aber meine Zeit ist sehr teuer, und somit spart jedes zusätzliche Werkzeug, das ich sinnvoll nutzen kann, echt Geld ein. Dass das kein Allheilmittel ist, ist auch klar. Aber machtmal spart es echt Zeit. Und ein Simulator hilft in diesem speziellen Beispiel auch nicht weiter. Meistens wird nämlich nicht die Peripherie mit simuliert. Da hilft nur echte Hardware für echte Ergebnisse. Was nicht heißt, dass Simulator nicht auch nützlich sein können. fchk
Am einfachsten lassen sich die STM32 mit der Arduino-IDE programmieren. Es gibt dazu verschieden Kerne: Beitrag "Re: STM32 Core Arduino Framework" >Nein, wenn Du in dem Bereich was studierst und auch privat damit dich >weiter beschäftigen willst, verwende STM32, z.B. den STM32 Bluepill bei >ebay für 2€ Nur weil es billig ist, fahren alle auf die BluePills ab. Ich würde die nicht nehmen und eher gleich auf ein STM32F4 Discovery mit Float setzen.
Das hier ist auch nicht schlecht, man braucht aber einen Programmieradapter: https://www.mikrocontroller.net/attachment/preview/328681.jpg
pegel schrieb >Eigentlich habt ihr alle nichts anderes getan, als mit vielen Worten >meine 2 Sätze zu bestätigen. ;) Nimm den AVR.. Der ist einfacher zu verstehen, die Hardware ist einfacher und Ihr werdet deutlich schneller zum Ziel kommen mit dem AVR. Wie viele Seiten hat ein Datenblatt eines AVRs, und wie viele Seiten hat ein Datenblatt eines STM32? Gruss, Jan
>Nimm den AVR.. >Der ist einfacher zu verstehen, die Hardware ist einfacher und Ihr >werdet deutlich schneller zum Ziel kommen mit dem AVR. Nimm das Arduino-Framework, dann ist der darunter liegende Prozessor egal.
Marc schrieb: > und eher gleich auf ein STM32F4 Discovery mit Float setzen. Einen STM32F4 für eine Toaster Statemachine? Ich glaube, du hast nicht mehr alle Streusel auf dem Kuchen! Nichts gegen STM32F4... Die tun es schon... Aber für eine Toaster Ablaufsteuerung? Ich kann es mir nicht vorstellen, ohne gleichzeitigen Lachzwang. Jan W. schrieb: > Nimm den AVR.. > Der ist einfacher zu verstehen, die Hardware ist einfacher und Ihr > werdet deutlich schneller zum Ziel kommen mit dem AVR. Ja, das stimmt! Ein AVR ist wirklich viel besser geeignet, als ein AVR! ;-)
Ihr empfehlt einem Studenten ernsthaft das Arduino Framework? Da kann ich nur den Kopf schütteln. Das ist doch Spielzeug! B-Anfänger: Frag mal deinen Professor, was der von Arduino hält. Darauf kommt es an.
B-anfänger schrieb: > ich bin im dritten Semester Hoffentlich in Germanistik oder "irgendwas mit Medien". Für einen technischen Studiengang ist die Frage peinlich. Ein MINT Student der es Wert wäre, hätte sich an einem Wochenende in die Materie eingearbeitet und könnte danach loslegen.
Nimm entweder einen Arduino (AVR ATmega µC) und programmier mit der Arduino IDE in C++ (viel Unterstützung von Leuten auf deinem Niveau) oder nimm einen STM32F4 (ARM µC) und programmier mit mBed in C++. Beide machen es dir einfacher in die Welt der µC einzutauchen. AVR ATmega µC mit dem Atmel Studio in C zu programmieren geht zwar auch, erfordert aber zuviel Einarbeitung. Versuch auf keinen Fall mit Assembler zu programmieren. Andere µC als die genannten bieten im deutschen Raum m. M. n. auch zu wenig Unterstützung, von der du am Anfang viel brauchen wirst. PIC geht zwar auch noch, tut aber keine Not den zu wählen. Das Forum ist hier eigentlich auch gut geeignet. Leider gibt es hier auch viele von der Art von Mitgliedern, die dir mit "Sollen wir deine ganze Hausaufgabe für dich machen? Da musst du selbst drauf kommen!"-Beiträgen den Spaß an der Sache nehmen wollen und sich als Lehrmeister aufspielen. Ist mir jedenfalls aufgefallen und von dem was ich in diesem Thema gelesen hab gibt es auch hier schon die ersten Beiträge in die Richtung. Gibt aber auch viele Mitglieder hier, die dir bei jedem Problem helfen werden. Ach ja, ich denke für deine Anwendung sind beide µC mit den verfügbaren Schnittstellen (GPIOs, ADC, PWM, TIMER, SPI, I²C, UART) und der Leistung für deine Anwendung ausreichend. Was für Sensoren braucht ihr/du denn für deinen Toaster. Schon was überlegt? Die müssen ja dann auch entsprechende Temperaturen aushalten. Der µC darf dann nicht in der heißen Umgebung sein. Das sollte dir allerdings klar sein.
B-anfänger schrieb: > Einen Toaster der den Toast möglichst perfekt gart mit thermischer > Auswertung der Brotoberfläche. Da würde ich die Auswahl des MC ganz nach hinten stellen und erstmal ein Konzept machen und die nötigen Sensoren, Aktoren und Algorithmen evaluieren. Es bringt nichts, mit dem unwichtigsten Teil der Aufgabe anzufangen.
Johannes S. schrieb: > (soll es wirklich eine > Toastersteuerung werden?) noch die nRF51/52, Cortex-M0/4 mit Bluetooth > Hardware. Dann kann der Toaster den Toaststatus gleich an eine > Smartphone App schicken. Bei Android kann sogar eine "Toast-Message" angezeigt werden ;-)
>thermischer Auswertung der Brotoberfläche
sollte Hauptthema sein. Nicht Befehlssatz der CPU. Hört sich eher nach
Peripherie (analog) an.
Timo N. schrieb: > Nimm entweder einen Arduino (AVR ATmega µC) und programmier mit > der > Arduino IDE in C++ (viel Unterstützung von Leuten auf deinem Niveau) > oder nimm einen STM32F4 (ARM µC) und programmier mit mBed in C++. > > Beide machen es dir einfacher in die Welt der µC einzutauchen. > > AVR ATmega µC mit dem Atmel Studio in C zu programmieren geht zwar auch, > erfordert aber zuviel Einarbeitung. > > Versuch auf keinen Fall mit Assembler zu programmieren. Andere µC als > die genannten bieten im deutschen Raum m. M. n. auch zu wenig > Unterstützung, von der du am Anfang viel brauchen wirst. PIC geht zwar > auch noch, tut aber keine Not den zu wählen. Der Arduino ist kein µC, sondern die Kategorie Lego Technik. Für Studenten geht es in Richtung dessen, was man in der Industrie später auch tun wird. Lernen für die Praxis ist das Ziel. Und da ist der Arduino einfach keine Option. Denn den baut auch der zukünftige Arbeitgeber nicht auf seine Platinen. Den ATMEGA im Atmel-Studio in C wäre eher realistisch - das sieht man durchaus auch mal in der Praxis. Der STM32F4 ist für Anfänger viel zu kompliziert. Wenn schon STM32, dann einen F0, der ist um einige simpler. STM32F051 wäre ein guter Anfang. Gibts Discovery-Boards für 10€ dafür. Stundenten sollen professionelle Entwicklung lernen, keinen Phyton Pfusch mit Raspberry PI oder Arduino-Gefrickel. Dafür muss man nicht studieren. PS: Deine Vorstellung von PIC ist niedlich-naiv. So ein PIC32MZ ist durchaus die gleiche Kategorie wie ein STM32F4 ;-)
Hallo B-anfänger, Peter D. schrieb: > Da würde ich die Auswahl des MC ganz nach hinten stellen und erstmal ein > Konzept machen und die nötigen Sensoren, Aktoren und Algorithmen > evaluieren. Genau das würde ich dir auch raten. Es ist sinnlos sich zu Anfang auf einen Kontrolertyp festzulegen um dann im Nachhinein festzustellen, das ein anderer Typ womöglich die notwendigen Sensoren/Aktoren viel besser unterstützt und dir damit eine Menge Arbeit spart. rhf
jemand schrieb: > Der Arduino ist kein µC, sondern die Kategorie Lego Technik. Für > Studenten geht es in Richtung dessen, was man in der Industrie später > auch tun wird. Lernen für die Praxis ist das Ziel. Und da ist der > Arduino einfach keine Option. Denn den baut auch der zukünftige > Arbeitgeber nicht auf seine Platinen. Den ATMEGA im Atmel-Studio in C > wäre eher realistisch - das sieht man durchaus auch mal in der Praxis. Unfug! Man kann durchaus auf die ganzen Arduino Komfort Funktionen verzichten. Und dann ist ein UNO nicht mehr als ein ATMega328p. Ein solches Programm lässt sich dann auch problemlos auf Atmel Studio, oder anderen IDEs, übertrage. Ein umbenennen von *.ino zu *.cpp sollte kein unüberwindliches Hindernis darstellen. Ja! Arduino geht auch ohne loop() setup() und delay()
Arduino Fanboy D. schrieb: > Ja! > Arduino geht auch ohne loop() setup() und delay() NEIN! Dann ist es kein Arduino mehr. Arduino ist nicht nur die Platine. Sondern das Gesamtkonzept aus Hardware, Framework und IDE. Schmeißt du alles bis auf die HW weg, ist es nur noch ein ATMega auf nem Board.
Cyblord -. schrieb: > NEIN! Dann ist es kein Arduino mehr. Gut, dann schreibe ich es nochmal extra für dich um: Die Arduino IDE kompiliert den Kram auch, wenn kein loop() setup() und delay() im Quellcode vor kommt. Cyblord -. schrieb: > Sondern das Gesamtkonzept aus Hardware, Framework und IDE. Is klar! Dir wurde vom lieben Gott die Deutungshoheit zugesprochen! Nee... Im Ernst: Ein Beispiel aus meiner Praxis... Ich entwickle gerne auf dem UNO. Die fertigen Programme sollen dann später oftmals auf einem Tiny85 laufen. Die dann oftmals nötige "Schrumpfung" des Codes lässt sich durch den Verzicht auf das Arduino Framework erreichen. Dafür wechsle ich dann nicht die IDE. Ja, Arduino ist ein Gesamtkonzept. Also IDE + Framework Aber man kann es auch trennen. Auch wenn du es nicht wahr haben willst. Das Framwork tuts auch mit Atmel Studio und Eclipse Die Arduino IDE tuts auch ohne Framework. Und dabei ist es völlig egal, ob dir das in den Kram passt, oder auch nicht.
Beitrag #5619109 wurde von einem Moderator gelöscht.
Beitrag #5619113 wurde von einem Moderator gelöscht.
Beitrag #5619120 wurde vom Autor gelöscht.
Das komische daran ist, das du die ganzen Entwickler und das ganze Unternehmen hinter dem Arduino nicht zu "Industrie" zählst. Industrie ist nicht nur Daimler, Bosch und Co. Klar verwendet man dort keinen Arduino und ich hab auch nie gesagt, dass man das in der "Industrie" macht. Es geht bei solchen Studentenarbeiten nicht immer darum gleich auf Registerebene runtergehen zu müssen. Hier geht es auch um das Systemdesign als Ganzes. Wenn man sich da weniger um den µC kümmern muss, ist damit in wirtschaftlicher Sicht (Zeitersparnis) auch geholfen. Außerdem hab ich auch nie geschrieben, dass Arduino ein µC ist. Ich hab in Klammern extra "AVR ATmega µC" geschrieben. Für den Toaster reicht Arduino. Fertig. Selbst bei Arduino lernt man genug. Man muss auch Abstrahieren können.
Arduino Fanboy D. schrieb: >> Der Arduino ist kein µC > Unfug! Wenn wir "Experten" von Arduino schreiben, meinen wir die IDE und das Framework, nicht den Mikrocontroller. Blöd ist nur, dass viele Arduino Nutzer es genau anders herum halten. Für sie sind Chip, Board, IDE und Framework alles eine Einheit.
Stefanus F. schrieb: > Arduino Fanboy D. schrieb: >>> Der Arduino ist kein µC >> Unfug! Das ist ein bis zur Unkenntlichkeit verzerrendes Zitat. Das nehme ich dir jetzt ernsthaft übel! NIEMALS HABE ICH BEHAUPTET DAS EIN µC ARDUINO IST Stefanus F. schrieb: > Wenn wir "Experten" von Arduino schreiben, meinen wir die IDE und das > Framework, nicht den Mikrocontroller. Wenn Expertentum bedeutet, dass man grob vereinfacht, alles in einen Topf wirft und dann seine Arduinoablehnung daraus konstruiert und mit Verachtung in die Welt bläht.... Dann will ich kein Experte sein! Ein solches Verhalten, oder die Art und Weise so seine Ansichten zu bilden, überlasse ich gerne den Rassisten und vergleichbarem Gelumpe. Damit will ich nichts zu tun haben. Klarer: Das ist keine Expertenmeinung, sondern nur Blähungen von irgendwelchen Lumpen. Bedenke: Die Möglichkeit, auf das Framework zu verzichten, wurde ABSICHTLICH in die Arduino IDE integriert. Das kann kein selbst ernannter Experte negieren.
Hi >Bedenke: >Die Möglichkeit, auf das Framework zu verzichten, wurde ABSICHTLICH in >die Arduino IDE integriert. Man kann sogar auf das ganze Arduino-Gedödel komplett verzichten. MfG Spess
spess53 schrieb: > Man kann sogar auf das ganze Arduino-Gedödel komplett verzichten. Natürlich geht das! Niemals würde ich jemanden drängen Arduino "Gedödel" zu nutzen. Soll doch jeder nach seiner Fasson glücklich werden... Solange er nicht anderen ins Essen spuckt. Mir geht nur die ablehnende Haltung, der selbst ernannten Experten, gegen Arduino etwas auf den Keks. Mich beschleicht die Annahmen, dass das Geschrei und die Ablehnung, bei denen am größten ist, welche sich am wenigsten damit beschäftigt haben. evtl. der typische "Mount Stupid" Effekt.
Arduino Fanboy D. schrieb: > Ich entwickle gerne auf dem UNO. Herzliches Beileid. Im Vergleich zu einem Texteditor ohne Debugmöglichkeiten ist mein STM32F051 mit ST-Link (Abgebrochen von einem abgerauchten F3-Discovery-Board) am IAR (freie Version) ja direkt super. Man muss seine Situation immer relativ betrachten, merke ich gerade.
Arduino Fanboy D. schrieb: > Mir geht nur die ablehnende Haltung, der selbst ernannten Experten, > gegen Arduino etwas auf den Keks. Das ist nicht der Kern der Angelegenheit. Sondern: auch ICH habe etwas dagegen, was die Philosophie hinter Arduino betrifft, nämlich, daß es eine Hardwarebasis sein soll für Leute, die ausdrücklichst sich NICHT mit der Hardware befassen wollen, die sie zu benutzen gedenken. Das geht nicht gegen die Boards und ihr diverses Zubehör und auch nicht gegen das Verwenden von Programmier-Bausteinen, wenn es für's Ziel ausreichend ist, SONDERN es geht gegen das dedizierte Sich-Nicht-Befassen-Wollen mit dem Werkzeug, was man benutzen will. Das ist der eigentliche Punkt. Zur Zeit gibt's grad einen Thread, wo sich jemand beklagt, daß bei seinem Arduino die Analog-Eingänge, die er überhaupt nicht beschaltet hat und die deshalb herumfloaten, ein fettes Übersprechen zeigen mit dem einzigen Analogkanal, den er tatsächlich beschaltet hat. Aber wenigstens vor der Klage hier im Forum die Nase mal in die Dokumentation zu stecken, ist wohl zuviel verlangt heutzutage. Diese Geistesveranlagung ist es, was auch meinen Zorn erregt. Ich hoffe, du kannst das nun verstehen. Nochwas: B-anfänger schrieb: > ich bin im dritten Semester und muss für ein Entwicklungsprojekt einen > Mikrocontroller verwenden und weiß nicht welchen ich verwenden soll. So ist das also. Ich sag dir dazu, daß du in exakt diesem Falle das für dich falsche Studienfach gewählt hast. In deinem Falle sollte man, sofern man bereits im 3. Semester ist, genug eigene Bastelerfahrungen haben, um sich diese Frage selbst zu beantworten, indem man den µC nimmt, mit dem man seine bisherigen Bastelprojekte gemacht hat und den man folglich bereits ausreichend kennt. Ich hätte vollstes Verständnis für dich, wenn du z.B. Chemie studiertest und dabei auch ein Semester "Informatik" hättest, das du mit einem kleinen in Java (ab)geschriebenen Progrämmchen als Beleg abschließen müßtest. Aber in deinem Falle liegt die Wahrheit ja ziemlich anders. W.S.
W.S. schrieb: > Ich sag dir dazu, daß du in exakt diesem Falle das für > dich falsche Studienfach gewählt hast. In deinem Falle sollte man, > sofern man bereits im 3. Semester ist, genug eigene Bastelerfahrungen > haben, B*llsh*t. Ich habe auch erst zur Diplomarbeit angefangen mich näher mit µC zu beschäftigen (auch Dank des Tutorials hier!). Elektrobasteln war und ist keine Voraussetzung um durch das Studium zu kommen, auch wenn es sehr hilfreich ist, wenn man nicht nur theorisches Wissen besitzt.
Mein Gott ist das ein Saftladen: fossile 8051er, ungeliebte PIC, komplizierte AVR, unmögliche ARM, gehirnerweichende Programmierumgebungen...
Und fast ausgestorbene 16-Bitter sollte man noch erwähnen!
Knuff schrieb: > Elektrobasteln war und ist keine Voraussetzung um durch das Studium zu > kommen Jepp, interessanterweise arbeiten sogar viele Leute die gute Komponenten brauchen professioneller als die ambitionierten Bastler. Die überlassen es einfach denen die sich damit besser auskennen. Ein gutes Lastenheft, Pflichtenheft und Doku sind genauso wichtig. Der eine ist der Hardwarefreak, der andere ein Manager. Und es muss nicht jeder Hardwarefreak sein.
W.S. schrieb: > Diese Geistesveranlagung ist es, was auch meinen Zorn erregt. Ich hoffe, > du kannst das nun verstehen. Zum Teil. Ich habe versucht deinen Beitrag aufmerksam zu lesen. Und kann schon den Frust verstehen, den man empfindet, wenn sich das Gegenüber als recht lernresistent erweist. Denn bin selber nicht frei davon. Aber dennoch nehme ich einen etwas anderen Standpunkt ein. Arduino hat das µC Gedönse für die große Masse verfügbar gemacht. Unmengen Leute schlagen da ein. Ab 10 bis 11 Jahre, bis ins hohe Alter. Von diesen, schätze ich mal, bleiben 10% bei der Stange. Und das sind garantiert genau die, welche nur selten in Foren auffallen. Soll man denen mit einem vorgefassten Urteil entgegentreten, und mit Schmähungen erniedrigen? Bedenke, die Frischlinge schlagen mit null Vorwissen ein. Im günstigsten Fall, dauert es 3 bis 4 Jahre, bis sie in Sachen Hardware und Softwareentwicklung halbwegs fit sind. Oder sind es eher 10 Jahre? Eine gute Strategie scheint mir zu sein, da Geduld zu üben! Denn diejenigen, welche das Programmierer Gen nicht haben, schmeißen über kurz oder lang, die Brocken in die Ecke. Und verschwinden. Die Alternative wäre alle Arduino Jünger gnadenlos aus dem Forum zu verbannen. Eine elitäre Gesellschaft schaffen, wo jeder nur nach einem Eignungstest mit machen darf. Stelle ich mir schwierig vor, das durchzusetzen. Auch bezweifle ich, dass die Arduino Plattform geschaffen wurde, den Anwender von der Hardware fern zu halten. Eher im Gegenteil. Irgendwelches Geheimwissen ist mir nicht bekannt. Vielleicht nicht immer gut dokumentiert, aber es liegt alles im Quellcode vor. Ebenso alle Schaltpläne, auch die Layouts, z.V. als Vorlagen für eigene Entwicklungen. Wer will, kann reinschauen. Und irgendwann versteht er dann auch was er sieht (vielleicht). Ja, geschaffen, für den leichten Einstig. Hat aber doch eine gehörige Breite und Tiefe, wenn man sich darauf einlässt.
Vielleicht sollte man nach Verfügbarkeit auswählen. So ein STM32 in einer bestimmten Version unter hunderten Versionen wird langfristig nicht ersetzbar sein. Vermutlich wird der Ur-8051 dagegen ewig produziert werden. Bei den AVR hängt es wohl von der Firma Microchip ab, die haben das ja übernommen.
Upps schrieb: > Vielleicht sollte man nach Verfügbarkeit auswählen... langfristig verfügbar Das ist so ziemlich das unsinnigste Argument, was man in dem Zusammenhang (Semesterprojekt) anführen kann. Da wird so gut wie nie ein Produkt draus. Muss auch nicht und ist auch nicht Ziel. Ihr müsst eine Aufgabe lösen und dafür gibts hunderte Möglichkeiten. Die Anwendung an sich klingt nach pillepalle -> völlig Wurscht, welchen MC ihr wählt, das kann jeder. Hilfreich sind Vorkenntnisse einer Familie. Spart sehr viel Zeit, die gerne mal knapp wird. Wenn es keine Präferenzen gibt, nehmt das was der Prof kennt - Wohlwollen garantiert.
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.