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?
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.
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 WS2812LEDs 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.
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.
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 ;-)
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.
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.
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.
