Moin,
ich möchte mir einen digitalen Regler für einen DC-Motor bauen.
Dazu möchte ich gernen einen entsprechenden Mikrocontroller kaufen.
Welchen sollte ich nehmen? Gerade was die Taktrate angeht bin ich mir
unsicher, wie schnell der Mikrocontroller sein muss. Die Takrate wirkt
sich ja auf die Berechnungsgeschwindigkeit der Stellgröße aus und
vermutlich auch auf die Samplerate vom AD-Wandler. Gibt es da ein paar
Tipps, wie man bei der Auswahl vorgeht?
Ozopftisch schrieb:> Gibt es da ein paar Tipps, wie man bei der Auswahl vorgeht?
Man nimmt die Plattform, mit der man Erfahrung hat, daraus das
Flaggschiff mit den Eigenschaften die man braucht.
Wenn Du so fragst, brauchst Du auch ein fertiges Evaluierungsboard.
Wenn der uC am Ende zu schnell ist: egal, 2Euro Lehrgeld.
Wenn er am Ende zu langsam ist, weisst Du, worauf es ankommt und kannst
dein Projekt in ein paar Tagen auf eine 100 Mal schnellere Plattform
portieren. Der Code, die HW-Treiber, die Erfahrung sind ja schon da.
Da reicht jeder Tiny dafür aus.
Ich habe vor 12 Jahren mal mit einem ATMega32 3 Achsen gleichzeitig via
PID geregelt und nebenbei noch ein Display mit Eingaben angesteuert.
Such Dir also was aus, was Dir gefällt.
Ozopftisch schrieb:> Moin,>> ich möchte mir einen digitalen Regler für einen DC-Motor bauen.> Dazu möchte ich gernen einen entsprechenden Mikrocontroller kaufen.> Welchen sollte ich nehmen? Gerade was die Taktrate angeht bin ich mir> unsicher, wie schnell der Mikrocontroller sein muss. Die Takrate wirkt> sich ja auf die Berechnungsgeschwindigkeit der Stellgröße aus und> vermutlich auch auf die Samplerate vom AD-Wandler. Gibt es da ein paar> Tipps, wie man bei der Auswahl vorgeht?
Nimm nen Brushlessregler von Hobbyking und schreib für den uC selbst ein
Programm
Ingo Less schrieb:> Man kann auch zu einem AVR greifen, aber wozu?
Weil die einfacher zu programmieren sind. Und die Frage des TO läßt
nicht auf Erfahrungen mit uCs schließen.
Bleibt auch die Frage für was man da einen AD-Wandler braucht. Einen
Encoder auf die Achse draufgeflanscht und gut ist.
Ozopftisch schrieb:> Gibt es da ein paar Tipps, wie man bei der Auswahl vorgeht?
Da du überhaupt keine Infos zu dem zu regelndem Dingsbums gegeben hast,
nehme ich an, dass du erstmal die Grundlagen der Thematik erlernen
möchtest. Damit das ganze auch ein bisschen Spaß macht, würde ich Dir
empfehlen, einen NiboBee Roboter-Bausatz (50€) zu kaufen. Da hast du
gleich zwei Motoren, die du regeln kannst.
Wenn du keinen Bock auf das Zusammenlöten hast, kannst du den von meinem
Sohn abkaufen. Er ist nicht 100% sauber verarbeitet, aber funktioniert
einwandfrei.
Was die Rechenleistung angeht: Dieser NiboBee hat einen 8bit
Mikrocontroller aus der AVR Serie mit 15 MHz Taktfrequenz. Das reicht
locker flockig aus, um die beiden Antriebmotoren zu regeln, zugleich mit
einem PC zu kommunizieren und diverse Sensoren abzufragen.
Dazu empfehle ich meine Notizen:
http://stefanfrings.de/nibobee/index.html
Dort siehst du auch ein Foto von Sohnemanns Roboter.
Andreas B. schrieb:> Weil die einfacher zu programmieren sind.
Wieder so eine, aus der Luft gegriffene, Behauptung. :-<<<
Selbst die größten AVR Jünger hier aus dem Forum sind auf ARM
umgestiegen. Waum wohl?
@Ozopftisch
Lass die Finger von dem veralteten AVR Krams. Nimm einen Cortex M. Egal
ob von ST, NXP, MC, oder ...
MaWin schrieb:> Andreas B. schrieb:>> Weil die einfacher zu programmieren sind.>> Wieder so eine, aus der Luft gegriffene, Behauptung. :-<<<>> Selbst die größten AVR Jünger hier aus dem Forum sind auf ARM> umgestiegen. Waum wohl?>> @Ozopftisch> Lass die Finger von dem veralteten AVR Krams. Nimm einen Cortex M. Egal> ob von ST, NXP, MC, oder ...
Das sehe ich ähnlich obwohl ich immer noch mit AVRs arbeite. Ich hab vor
über 20 Jahren mit dem Kram angefangen und mir genügen die AVRs, daher
bleib ich bei denen, mir fehlt zur Zeit so ein wenig die Motivation noch
habe ich einen Zwang auf was Neueres umzusteigen. Aber wenn heute jemand
beginnt sollte er nach aktuellen Sachen schaun, AVRs wie so nen tollen
Atmega328 sind zwar ganz nett aber warum so ne Krücke nehmen wenn man
preiswerter mit Cortex M-irgendwas rumspielen kann? Und wirklich schwer
zu handhaben sind die Cortex-Teile auch nicht.
Andreas B. schrieb:> Ingo Less schrieb:>> Man kann auch zu einem AVR greifen, aber wozu?>> Weil die einfacher zu programmieren sind.
Kann ich nicht bestätigen; die Eclipse Entwicklungsumgebung CubeIDE zum
STM32 ist doch super gemacht mit dem integrierten Debugger und
Speicher-Analyzer und mit CubeMX und der HAL ist schon sehr viel
integriert was man immer wieder braucht, sogar FreeRTOS ist mit ein paar
Mausklicks integriert und läuft auch sofort.
Um einen Motor (Masse) zu regeln, braucht's keinen "großen"
Mikrocontroller.
Das machen die meisten Teile im Halbschlaf.
Und die Teile, die Du sonst noch brauchst, werden sowieso über I/O-Pins
oder irgend etwas (halb-)serielles Angesteuert.
Ausnahme ist natürlich, wenn Du noch eine Salami aufschneiden willst und
das Teil noch einen 19" Monitor ansteuern können sowie Waschen und
Bügeln erledigen soll.
Es gibt von diesen Firmen [Anzahl]:
- ST: 850
- NXP: 400
- TI: 500
- Analog: 200
- Microchip: 1000
- ... noch diverse andere Hersteller ... 10000
Mikrocontroller die für Deinen Zweck ausreichend sind. Falls Du nicht
genauere Wünsche schreibst suche Dir selbst einen von den genannten
11950 Typen aus.
Naja, wenn er einen Kaskadenregler machen will und Positionen schnell
anfahren, dann brauchts schon ordentlich Rechenleistung und dann
empfiehlt sich auch einer mit FPU. z.B. der STM32F30x ist gut geeignet
für solche Anwendungen.
MaWin schrieb:> Wieder so eine, aus der Luft gegriffene, Behauptung. :-<<<
Nö, alleine die Clockconfigurationen übersteigen die des AVR bei weitem.
Auch daß man jeden Peripheriebaustein extra anschalten muß.
Johnny B. schrieb:> Kann ich nicht bestätigen; die Eclipse Entwicklungsumgebung CubeIDE zum> STM32 ist doch super gemacht mit dem integrierten Debugger und> Speicher-Analyzer und mit CubeMX und der HAL ist schon sehr viel> integriert was man immer wieder braucht, sogar FreeRTOS ist mit ein paar> Mausklicks integriert und läuft auch sofort.
Das mag ja alles sein, daß man mit entsprechender IDE da weiter kommt,
aber mach das ganze mal auf gcc und make Ebene. Dann siehst Du was
einfacher ist. Ich selbst bin kein Freund von überladenen IDEs. Aber das
ist wohl Geschmackssache.
Ich finde es nur lustig, daß viele über Arduino herziehen, aber solche
IDEs, die die Komplexität der ARMs vor dem Benutzer verbergen,
akzeptiert werden.
Aber egal, der TO hat sich ja wohl schon entschieden.
Andreas B. schrieb:> Clockconfigurationen übersteigen die des AVR
Und den AVR dabei wieder verfusen und dann weg mit dem Chip, oder
kompliziert wieder beleben. :-(
Alle steigen um, von AVR auf ARM. Warum nur? Sicherlich nicht an den
"anspruchsvollen" Projekten. ;-)
MaWin schrieb:> Alle steigen um, von AVR auf ARM.
Ich nicht. ;-) Ich habe auch noch keine Anwendungen wo ich die
Rechenleistung eines kleinen ARMs benötigen würde. Wenn ich Displays und
WLAN brauche, nehme ich Nanopi's u.ä..
Nicht, daß wir uns falsch verstehen: Ich habe nichts gegen ARMs. Sie
mögen oft auch genau das richtige sein. Nur davon auszugehen, daß die
alle Welt jetzt braucht, stimmt so einfach nicht.
Andreas B. schrieb:> wo ich die> Rechenleistung eines kleinen ARMs benötigen
Gääähhhnnn.
Andreas B. schrieb:> Sie> mögen oft auch genau das richtige sein. Nur davon auszugehen, daß die> alle Welt jetzt braucht
Keiner braucht irgendeinen uC. Aber wenn man einen uC einsetzen will,
nimmt halt keinen 68HC oder AVR mehr. So einfach ist das.
MaWin schrieb:> Selbst die größten AVR Jünger hier aus dem Forum sind auf ARM> umgestiegen. Waum wohl?
Ja warum?
Ich bezeichne mich immer noch als Anfänger und meine behaupten zu können
das es zum AVR in Form des Arduino (auch tiefer gehend und nah am µC
selbst wenn man nur will) aber auch als "nackten" AVR in C oder sogar
(leider letztendlich doch wenig was wirklich gut gemacht ist) in
Assembler die meiste und beste Unterstützung gibt.
Mittlerweile etwas abgeschlagen wird auch der PIC recht gut unterstützt,
der meiner Meinung von Konzept her aber deutlich umständlicher ist wenn
Assembler genutzt werden soll (Was man zumindest einmal etwas
tiefergehender mit irgendeinen µC gemacht haben sollte wenn man wirklich
verstehen will wie so ein µC funktioniert).
ARM Tutorials und Literatur die sich an Einsteiger wendet und wirklich
gut erklärt scheinten mir doch wesentlich dünner genäht zu sein und
entweder sehr weit weg von der Hardware (Arduino in der Art und Weise
wie sie durchaus zu recht hier sehr kritisch gesehen wird) oder wenn
doch noch einigermaßen nah an der Hardware (C oder gar Assembler) aber
ganz bestimmt nicht mal für den fortgeschrittenen Anfänger geeignet wenn
es dann um das geht was halt die AVR nicht mehr schaffen.
Also warum ARM?
Nur wegen des Preis/Leistungsverhältnis? Das ist dann aber letztendlich
doch meist nur noch ein Argument für die echten Profis bzw. Hobbyisten
die vom Wissen und der Erfahrung es auf Profiniveau angekommen sind.
Selbst mit einen "kleinen" AVR und erst recht mit den "großen" kommt man
rein von der Leistung bei den meisten Anwendungen nicht an den
Leistungsgrenzen, und wenn irgendwas mit Codecs, Audio, Filter usw.
gemacht werden soll werden ja (zum Teil leider - auch auch
verständlicher Weise)fertige Module angewendet wo man "nur" die
Schnittstelle beherrschen muss, oft genug gibt es sogar direkt fertige
Bibliotheken dazu (Was bedauerlich aber so widersinnig es klingen mag
gleichzeitig auch genial ist).
Also warum ARM?
Oder vielleicht besser gefragt: Für wen und warum ARM?
Jemand
MaWin schrieb:> Alle steigen um, von AVR auf ARM
Durch Wiederholung wird dieser Quatsch auch nicht wahrer.
Andreas B. schrieb:> Ich nicht.
Ich auch nicht. Ich benutze beide - je nach Anwendungsfall.
Vorweg: Nicht zu ernst nehmen:
Warum "Eight Bitter"?
Vielleicht als "leisurely" Abwechslung für Profi-Entwickler die sich im
Betrieb mit 32-Bittern Bolliden Jahraus, Jahrein herumschlagen müssen,
wo die Programme oft 50000-1Mio+ Zeilen verschlingen und alles
Verbrochene auf die Goldwaage gelegt wird. Programme so kompliziert daß
einem Hören und Sehen vergeht und der Kopf zum Rauchen anfängt.
Wer von dem Allem dann immer noch nicht genug hat und trotzdem ein
bischen uC zum Spaß machen möchte, für dem sind die bescheideneren
kleineren uC Brüder dann vielleicht doch keine so schlechte Alternative.
Da ist dann sogar das verschrieene Arduino IDE eher ein Labsal. PIC ist
auch OK. Zur Abwechslung könnte man sogar noch mit dem modernen
FLASH8051er spielen.
Ja, ja! Gebt es doch zu. Ihr, aus dem Schrank kommend! Gar manche die
sich da in aller Heimlichkeit im geheimen Heimlabor mit trivialen Spaß
uC Projekten abgeben über die man sich im Betrieb als ernsthafter
Entwickler lieber die Zunge abschneiden ließe als zuzugeben, daß man
sich ab und zu damit abgäbe. Man kennt ja seine Pappenheimer...
Nach dieser schwierigen Wahrheitsfindung sollte es leicht sein,
zuzugeben, daß 8-Bitter in Wahrheit immer noch Kool sind und man nette
Sachen mit ihnen anstellen kann und am Wichtigsten, es Spaß macht mit
einfacheren Programmen die Gegend unsicher zu machen.
OK. Dann macht mal. Die Wahl sollte nicht schwer sein.
Der 8-Bitter ist tot. Es lebe der 8-Bitter!
Ein Schelm wer Böses dabei denkt - ich habe wirklich nichts getrunken;-)
MaWin schrieb:> Und den AVR dabei wieder verfusen und dann weg mit dem Chip, oder> kompliziert wieder beleben. :-(
Also nen HV-Programmer würde ich jetzt nicht als "kompliziert"
betrachten. Nur als "teuer" ;)
MaWin schrieb:> Keiner braucht irgendeinen uC. Aber wenn man einen uC einsetzen will,> nimmt halt keinen 68HC oder AVR mehr. So einfach ist das.
Da spricht die Erfahrung, das merken wir grade mal wieder. "Schuster,
bleib bei deinen Leisten" sach ich dazu nur, der µC-Profi warst du noch
nie, MaWin ;)
Blechbieger schrieb:> Es gibt von den meisten Herstellern Mikrocontroller die für> Motorsteuerungen optimiert sind. Z.b. STM32G4 Serie von ST oder Kinetis> V Serie von NXP.
In der AVR-Serie findest du so etwas auch oder meinst du, es ist Zufall,
dass z.B. ein Atmega328P 6 unabhängige PWM-Ausgänge hat ;)
Gerhard O. schrieb:> Ein Schelm wer Böses dabei denkt - ich habe wirklich nichts getrunken;-)
DAS glaub ich dir nicht :D
MaWin schrieb:> Und den AVR dabei wieder verfusen und dann weg mit dem Chip,> oder kompliziert wieder beleben. :-(
Quatschkopp.
> Alle steigen um, von AVR auf ARM.
Auch falsch.
> Warum nur? Sicherlich nicht an den "anspruchsvollen" Projekten. ;-)
Arduino lebt noch immer, auch mit AVR. Komisch, oder?
Jemand schrieb:> Also warum ARM
für Einsteiger?
Weil man heute keinen Faustkeil mehr nutzt. Kann ja sein, dass du durch
jahrzehnte Erfahrung der Meister des AVR Faustkeils bist und deine
Scheuklappen den Blick auf Neues verdecken.
Aber bitte gib anderen die Chance, mit aktuellen Werkzeugen zu arbeiten,
Danke!
Stefan ⛄ F. schrieb:> Ich benutze beide
? Sack Reis, in China ?
M. K. schrieb:> HV-Programmer
Braucht der Cortex nicht, also?
M. K. schrieb:> sach ich dazu nur, der µC-Profi warst du noch> nie
Begründet sich wie?
M. K. schrieb:> In der AVR-Serie findest du so etwas auch
Wenn man lange genug sucht, findet amn wahrscheinlich auch einen
entsprechenden 8051. Willst du den dann auch empfehlen? :-(
S. R. schrieb:> Arduino lebt noch immer
Wird auch weiter leben. Die setzen ja schon auf ARM. ;-)
Alle, die hier zum AVR raten, frickeln schon längst mit ARM. Seid doch
einfach ehrlich, Jungs!
MaWin schrieb:> Alle, die hier zum AVR raten, frickeln schon längst mit ARM. Seid doch> einfach ehrlich, Jungs!
Stimmt, hab ich mal gemacht und keinen Vorteil dabei gefunden.
Wenn man keine Verwendung für die Rechenleistung hat, lohnt sich das
eben nicht.
Und stell Dir vor: Mir fallen sogar viele Anwendungen für den Tiny10
ein.
Geh mal davon aus, daß 80% der Anwendungen, die im Netz mit einem Raspi
gemacht werden, mit einem ATTiny im Halbschlaf zu erledigen sind.
Andreas B. schrieb:> Raspi gemacht werden, mit einem ATTiny im Halbschlaf zu erledigen sind.
Das ist jetzt schon ein bisschen so als würde man Äpfel mit Birnen
vergleichen oder? ;)
MaWin schrieb:> Alle, die hier zum AVR raten, frickeln schon längst mit ARM. Seid doch> einfach ehrlich, Jungs!
Wir frickeln auch mit ARM. Wir sind aber (offensichtlich im Gegensatz zu
dir) in der Lage, AVR zu nehmen, wenn AVR Vorteile bezüglich der
Anwendung hat und ARM zu nehmen, wenn ARM Vorteile bezüglich der
Anwendung hat.
Sprich: wir sind (offensichtlich wieder im Gegensatz zu dir) einfach
kompetent und wissen: es gibt keinen "one fits all requirements
optimally" µC.
c-hater schrieb:
Mal wieder nicht gelesen worum es geht? Erst informieren, dann motzen. ?
Der TO fängt an und kennt keine zig Architekturen, zwischen denen er
wechseln kann. Du Riesenrakete schüttelst ja alle CPUs dieser Welt aus
dem Ärmel. Aber der arme Kerl muss sich das erst noch erarbeiten. Und
dann startet er natürlich mit dem Stand der Technik und nicht
irgendwelchen alten Kamellen.
Soweit die Zusammenfassung, extra für dich. ??
Guest schrieb:> Andreas B. schrieb:>> Raspi gemacht werden, mit einem ATTiny im Halbschlaf zu erledigen sind.>> Das ist jetzt schon ein bisschen so als würde man Äpfel mit Birnen> vergleichen oder? ;)
Es ist mir schon klar, daß man die meisten Anwendungen die mit Äpfeln
gemacht werden, genausogut mit Birnen erledigen könnte.
Der Kern meiner Aussage ist schlicht, daß für die meisten Anwendungen
die CPUs erheblich überdimensisoniert sind. Und zwar nicht x%, sondern
Faktor x.
Chipfrisch schrieb im Beitrag #6128969:
> Verschiedene Chips auf dem Tisch nebeneinander legen. Angucken und> ausprobieren welcher dir am besten schmeckt. Den nimmst du dann!
Dann würden bei mir AVR im PDIP Gehäuse gewinnen, denn die passen ohne
Adapter in Lochraster und auf's Steckbrett. Das ist für meine
Handgedengelten Einzelstücke ideal.
Wenn es STM32 ohne krassen Aufpreis für 2-5V in PDIP gäbe, würde ich
diese bevorzugen und mich über mehr Leistung/Funktionen freuen.
Maik schrieb im Beitrag #6129095:
> Die Behauptung so ein AVR Tiny oder Mega würde nur fürs Treppenlicht und> blinkende LEDs taugen zeugt von ziemlich viel Unkenntnis der> Leistungsfähigkeit moderner 8Bitter!
Ein Beispiel:
Bei mir decodiert ein ATtiny13 das DCF77 Signal samt Anzeige. Und zwar
in C, nicht in mühsam optimiertem Assembler.
Maik schrieb im Beitrag #6129095:
> Haltet die Dinge doch einfach! Das bedeutet nur allzu oft: Ein> kleiner 8Bitter samt Compiler auf die Aufgabe fokussiert tut es genauso!
Du denkst auch nur mit 8 Bit Leistung? ;-)
Um Dinge einfach zu halten nutzt man moderne, ausgereifte, einfach
bedienbare Dinge ohne Fallstricke. Und dabei scheiden die AVR aus und
man nimmt z. : einen ARM. So einfach ist das. :-)
Stefan ⛄ F. schrieb:> Chipfrisch schrieb im Beitrag #6128969:>> Verschiedene Chips auf dem Tisch nebeneinander legen. Angucken und>> ausprobieren welcher dir am besten schmeckt. Den nimmst du dann!>> Dann würden bei mir AVR im PDIP Gehäuse gewinnen, denn die passen ohne> Adapter in Lochraster und auf's Steckbrett. Das ist für meine> Handgedengelten Einzelstücke ideal.>> Wenn es STM32 ohne krassen Aufpreis für 2-5V in PDIP gäbe, würde ich> diese bevorzugen und mich über mehr Leistung/Funktionen freuen.
Na dann wirst Du sicher bei PIC24, dspic33 und PIC32 zugreifen. OK, nur
3.3V, aber DIL.
fchk
Nimm einen Cortex M0.
Ein Debugger dafür kostet nur 3€ (China).
Ein AVR ist zwar einfacher gestrickt, aber alles darum kostet mehr.
Der ist schnell genug und wäre für so eine Aufgabe meine erste Wahl.
MaWin schrieb:> M. K. schrieb:>> HV-Programmer> Braucht der Cortex nicht, also?
Du meintest einen verfused AVR muss man wegschmeißen. Meine Antwort war,
ein HV-Programmer lässt sich benutzen wie jeder andere Programmer auch
und damit hat man dann auch mit verfusen kein Problem mehr.
MaWin schrieb:> M. K. schrieb:>> sach ich dazu nur, der µC-Profi warst du noch>> nie> Begründet sich wie?
z.B. durch:
MaWin schrieb:> M. K. schrieb:>> In der AVR-Serie findest du so etwas auch> Wenn man lange genug sucht, findet amn wahrscheinlich auch einen> entsprechenden 8051. Willst du den dann auch empfehlen? :-(
Es werden auch heute noch jede Menge Derivate des 8051 gebaut (spontan
fällt mir z.B. die XC800-Serie ein oder DS89er von Maxim), da muss man
gar nicht lange suchen. Die Firmen müssen also entweder ganz schönen
Mist machen oder aber die Aussage stimmt, dass du noch nie der µC-Profi
hier warst. Aber das zeigen ja auch deine anderen Antworten hier im
Thread ;)
M. K. schrieb:> ein HV-Programmer lässt sich benutzen wie jeder andere Programmer auch
Eine veralterte Technik, die man bei modernen µCs nicht braucht. :-(
M. K. schrieb:> heute noch jede Menge Derivate des 8051 gebaut (spontan> fällt mir z.B. die XC800-Serie ein oder DS89er von MaximM. K. schrieb:> dass du noch nie der µC-Profi> hier warst
Na das passt ja gut zusammen. Wie verbreitet ist wohl der DS89er? Wenn
du Werbung für 8051 machen willst, solltest du SiLabs nennen. ;-)
Der 8051 Markt bedient Zukunftsverweigerer wie dich. ;-)
Wer heute einsteigt, nimmt keinen 8051, AVR oder sonst was Antiquares.
Der nimmt z. B. einen ARM.
MaWin schrieb:> Der nimmt z. B. einen ARM.
Du wiederholst Dich. Es wird langsam langweilig.
Klaus schrieb:> Ein AVR ist zwar einfacher gestrickt, aber alles darum kostet mehr.
Programmer aus der Bucht 3€. Selbstgestrickter HV Programmer (wenn man
ihn mal braucht) ebenfalls um die 3€.
Hilfe, ich werde arm.....
Na hier ist ja die geballte Kompetenz am Werkeln.
Manche Beiträge lesen sich wie ein Glaubenskrieg, gegen den die
Inquisation ja ein Kindergeburtstag war. Blos das hilft dem armen
Ozopftisch (sympathischer Name) nicht weiter.
Hier ein Beitrag, bei dem die Regelung von DC-Motoren ganz gut
beschrieben ist:
https://www.heise.de/select/make/2016/6/1482398401198797
Oje, da wird ja ein Arduino verwendet ;-)
Allen Glaubenskriegern empfehle ich die Konsultation eines Psychologen.
(Aber nehmt einen sehr guten! Ein guter wird nicht reichen).
Viele Grüße
Knallfrosch
Ozopftisch schrieb:> ich möchte mir einen digitalen Regler für einen DC-Motor bauen.> Dazu möchte ich gernen einen entsprechenden Mikrocontroller kaufen.> Welchen sollte ich nehmen?
Erstmal GAR KEINEN.
Entweder kennst du dich bereits damit aus, Algorithmen für digitales
Motor-Management und Regelung zu schreiben, dann setz dich hin und
schreibe selbige für deinen spezifischen Motor hin, um den
controller-UN-spezifischen und eigentlich wichtigsten Teil deiner
künftigen Firmware zu erstellen - oder:
Ja, oder: wenn du dich mit derartigen Algorithmen etc. noch nicht
auskennst, dann erlerne sie. Sowas ist tatsächlich unabhängig davon, was
du dir denn nun für einen Chip auszuwählen beabsichtigst.
Der Rest der ganzen Sache sind chipabhängige Lowlevel-Treiber. Aber die
kommen erst dran, wenn deine Algorithmen stehen.
Alles Andere ist nix als Herumwurschtelei.
W.S.
Knallfrosch schrieb:> Blos das hilft dem armen> Ozopftisch (sympathischer Name) nicht weiter.
Der TO ist schon lange draußen und hat sich für einen ARM entschieden.
> Hier ein Beitrag, bei dem die Regelung von DC-Motoren ganz gut> beschrieben ist:>> https://www.heise.de/select/make/2016/6/1482398401198797
Na ja, eine ordentliche Regelung macht man mit einem Encoder. Aber auch
davon schafft ein Tiny mindestens 3 gleichzeitig.
Knallfrosch schrieb:> Allen Glaubenskriegern empfehle ich die Konsultation eines Psychologen.> (Aber nehmt einen sehr guten! Ein guter wird nicht reichen).
Ich sehe nur einen Glaubenskrieger hier. Alle anderen sind flexibel, was
den Einsatz des passenden uC betrifft.
Wir achten im Betrieb bei der Auswahl eines uC immer auf minimale
Komplexität. Deshalb fahren wir eine Doppelstrategie:
Wir haben sowohl ARM Cortex als auch PIC (8-Bit) im Einsatz. Bei jedem
Projekt klären wir ab, ob ein PIC ausreicht. Die mögliche Auswahl
beschränkt sich derzeit auf insgesamt 5 verschiedene Typen in den Serien
PIC12 bis PIC18. Können wir uns für einen 8-Bit uC entscheiden,
programmieren wir in der Regel ohne viel HAL-Schnickschnack direkt auf
Registerebene.
Für rechenintensive Projekte setzen wir daneben Cortex M4 ein. Unser
Chef will aber immer eine saubere Begründung sehen, warum es nicht
einfacher geht.
Den ARM programmieren wir meistens mit HAL, der die Komplexität des Chip
bedient und den Anwender abschirmt.
Ich muss schon sagen: Das geht gut, aber so richtig wohl ist mir dabei
trotzdem nicht. Ich habe lieber den Chip bis ins Register im Griff. Bei
ARM ist das deutlich mühsamer (weil viel komplexer) als mit den PICs.
Daher heisst für mich die Devise: Zuerst Nachdenken, Abklärungen treffen
und danach die Lösung minimaler Komplexität nehmen. Und nicht
überraschend: Oft heisst diese Lösung 8-Bit - viel öfter als mancher
32Bit-Apostel glauben würde!
Ob es dann ein AVR oder PIC oder 8051 ist, ist dann wohl eher eine Frage
der Verfügbarkeit und Gewohnheit.
Alter Profi schrieb:> Wir achten im Betrieb bei der Auswahl eines uC immer auf minimale> Komplexität. Deshalb fahren wir eine Doppelstrategie:
So ähnlich läuft das in allen Unternehmen ab, die ich so bisher kennen
durfte incl. der Bergündung warum es dieser oder jene µC sein soll und
kein anderer ;)
Lassen wir bitte jetzt einfach mal dieses persönliche Herumgehacke und
das laufende, immer und ewigliche mantrahafte Wiederholen von "die
Architektur, die ich vertrete, ist die Beste".
Ich hatte das Glück, dass ich mit einem 8048 angefangen habe und dann
schnell zum 8051 samt Derivaten gekommen bin. Denn der Erstere konnte
quasi nichts, die Anderen nur wenig. Dehalb konnte man diese Dinger bis
aufs letzte Bit auswendig kennenlernen. Als dann endlich der AVR kam,
war der Umstieg simpel, denn dieser µC wurde anfänglich (dank
"Pinkompatibilität" der ersten Derivate) nur als 8051-Ersatz verwendet.
Im weiteren Verlauf kamen dann aber deutlich mehr Funktionalität und
etliche Register mit spürbaren Doppel- und Nebenfunktionen in die AVR
rein. Nach ein paar 16-Bit Ausflügen in die ST10 Ecke kamen dann endlich
die ARM-Prozessoren. Und die sind schon recht komplex. Ich bin froh,
dass ich mit diesen Dingern nicht anfangen musste.
Und heute würde ich zum Anfangen 1. einen verbreiteten µC empfehlen,
und 2. einen nicht zu komplexen. Bei 2. fallen die meisten ARM-Derivate
raus, bei 1. dann die restlichen.
Zur Lösung eines Problems würde ich aus dieser Palette idR. denjenigen
nehmen, mit dem das Problem am schnellsten zu lösen ist. Denn wie
richtig erkannt sind bis auf den 8048 noch alle Architekturen am Markt.
Und wenn die Aufgabe dann mal gelöst ist, dann kann bei entsprechenden
Stückzahlen ggfs. noch auf Kosten optimiert und dafür die Architektur
gewechselt werden.
Lothar M. schrieb:> Lassen wir bitte jetzt einfach mal dieses persönliche Herumgehacke und> das laufende, immer und ewigliche mantrahafte Wiederholen von "die> Architektur, die ich vertrete, ist die Beste".
Lieber Lothar, kannste auch mal im anderen Thread
(Beitrag "Weg von Arduino - Beratung") die Löschkeule schwingen?
Das wäre prima.
