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?
:
Dann nimm doch irgendeinen STM32 und tue Dich mit jemanden zusammen, der damit schon Erfahrungen hat.
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.
:
Bearbeitet durch User
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
STM32F0 im TSSOP 20 Gehäuse reicht dafür locker aus... Man kann auch zu einem AVR greifen, aber wozu?
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.
MaWin schrieb: > Selbst die größten AVR Jünger hier aus dem Forum sind auf ARM > umgestiegen. Waum wohl? Das hast du frei erfunden, stimmt's?
Stefan ⛄ F. schrieb: > Das hast du frei erfunden, stimmt's? Ei klar hat er das. Die sind auf AMD gewechselt ;)
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.
Danke, schon mal. Programmiert habe ich schon viel. Aber mit Mikrocontrollern hatte ich noch nichts zu tun. Ich versuchs dann mit dem Cortex STM32.
Ozopftisch schrieb: > Ich versuchs dann mit dem Cortex STM32. Viel Glück. Vielleicht helfen Dir meine Notizen für den Anfang: http://stefanfrings.de/stm32/index.html Hast du denn schon ein konkretes Ding, dass du regeln willst?
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
Beitrag #6127861 wurde vom Autor gelöscht.
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.
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.
Beitrag #6128969 wurde von einem Moderator gelöscht.
Beitrag #6128970 wurde von einem Moderator gelöscht.
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.
Beitrag #6129095 wurde von einem Moderator gelöscht.
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 Maxim M. 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.....
:
Bearbeitet durch User
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.
Beitrag #6129353 wurde von einem Moderator gelöscht.
Beitrag #6129357 wurde von einem Moderator gelöscht.
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 ;)
Beitrag #6129448 wurde von einem Moderator gelöscht.
MaWin schrieb: > Eine veralterte Technik, die man bei modernen µCs nicht braucht Autos mit Verbrennungsmotor sind auch veraltet. Merkst du was?
Beitrag #6129658 wurde von einem Moderator gelöscht.
Beitrag #6129957 wurde von einem Moderator gelöscht.
Beitrag #6129960 wurde von einem Moderator gelöscht.
Beitrag #6130233 wurde von einem Moderator gelöscht.
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.
Beitrag #6130406 wurde von einem Moderator gelöscht.
Beitrag #6130409 wurde von einem Moderator gelöscht.
Beitrag #6130450 wurde von einem Moderator gelöscht.
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.
Beitrag #6131272 wurde von einem Moderator gelöscht.
Beitrag #6133650 wurde von einem Moderator gelöscht.
Beitrag #6134759 wurde von einem Moderator gelöscht.
Beitrag #6135967 wurde von einem Moderator gelöscht.
Beitrag #6136065 wurde von einem Moderator gelöscht.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.