Guten Tag, ich habe mir auf dieser Seite die Artikel über AVR und ARM durchgelesen, meine Frage ist, welcher Controller ist für den Einsteiger besser geeignet? Erfahrung habe ich so gut wie keine im Umgang mit Controllern (an der Hochschule mal ne LED zum leuchten gebracht). Grundlagen im Programmieren mit C sind vorhanden. Ich will mich damit Hobbymäßig beschäftigen. Was könnt ihr aus eurer Erfahrung heraus empfehlen?
Arduino - große Comunity und viel im Internet. Für den Einstieg ohne viel Ahnung sehr gut. Nach den ersten Versuchen und etwas Erfahrung empfehle ich recht schnell den Wechsel zum ARM, da hier viel mehr möglich ist. z.B. STM32F0 Reihe. Artikel: STM32 für Einsteiger
Hi mit Atmek kenne ich mich weniger aus. Das hier wird dich aber sehr schnell zu erfolg bringen Alles für free, ausser 10-15 Euro für ein Nucleo ARM STM32 board Dieser Webinar ist echt coo. nach einem Tag hast du echt ein quick start. https://st-mooc.udemy.com/?next=%2Forganization%2Fdiscovery%2Fbrowse%2Fstmicroelectronics-learning-portal%2F4031580%2F%3Fpage%3D1
Markus M. schrieb: > Nach den ersten Versuchen und etwas Erfahrung empfehle ich recht schnell > den Wechsel zum ARM, da hier viel mehr möglich Wobei das natürlich stark vom Anwendungsfall abhängt. Solange man nur ein paar LEDs blinken lassen will oder eine Uhr mit einem DCF-77-Empfänger bauen, ist auch der AVR so sehr unterfordert, dass das alles keine weitere Geige spielt. Ein AVR braucht weniger „Brimborium“, um sinnvoll zu laufen als ein ARM. Im Prinzip genügt sehr oft schon der Standard-Takt von 1 MHz, dann kann man direkt loslegen, ohne sich irgendwie großartig um die Start-Konfiguration des Prozessors zu kümmern. Ein ARM möchte da schon ein bisschen „bemuddelt“ werden. Wenn man ihn nur mit den wenigen MHz Standard-Takt ab Reset betreibt, ist er eigentlich völlig für die Katz', sodass man sich erstmal ansehen muss, wer da drin nun mit welchen Takten versorgt werden sollte. Auch muss man die meisten Peripherals einzeln zum Takt dazuschalten, da sie standardmäßig aus sind, um Strom zu sparen. Klar ist das alles beherrschbar, auch für einen Anfänger, aber zurück zum ersten Satz: wenn man das alles gar nicht braucht, dann hat der ARM auch keinen Vorteil mehr. Über ein paar Cent im Preis braucht man sich als Bastler in der Regel keine Birne machen, sowas wie eine große Community bei Arduino ist da deutlich wichtiger.
Jörg W. schrieb: > Klar ist das alles beherrschbar, auch für einen Anfänger, aber zurück > zum ersten Satz: wenn man das alles gar nicht braucht, dann hat der > ARM auch keinen Vorteil mehr. Sehr vernünftig. Ein einfacher Einstieg ist ja insbesondere auch von Bedeutung, um motiviert zu bleiben. Für die meisten auch anspruchsvolleren Hobbyprojekte langt ein AVR schon mit wenigen MHz mehr als aus.
Beitrag #4952938 wurde von einem Moderator gelöscht.
Neulich hab ich ein I2C Slave mit einem STM32F030 programmiert. 8MHZ > zu langsam 24MHz > immer noch nicht OK 48MHz > sehr sporadisch nicht OK Interrupt Prioritäten verschoben > OK Manchmal denkt man es ist nur eine triviale Aufgabe - dennoch war ich froh eine flotte CPU mit umfangreichen Konfigurationsmöglichkeiten zu Anfang schon eingesetzt zu haben. Dennoch: Als Einstieg ist der Arduino so ziemlich das beste und man bekommt in vielen Foren Hilfe.
Beitrag #4952945 wurde von einem Moderator gelöscht.
Beitrag #4952950 wurde von einem Moderator gelöscht.
ASM Superprofi schrieb im Beitrag #4952938:
> Ich empfehle ganz klar den ATtiny13A.
Du hast die Ironie-Tags vergessen.
ASM Superprofi schrieb im Beitrag #4952938: > Ich empfehle ganz klar den ATtiny13A. Ja der ist echt super. Gibts im gut handlichen DIP-Gehäuse! Markus M. schrieb: > Neulich hab ich ein I2C Slave mit einem STM32F030 programmiert. > 8MHZ > zu langsam > 24MHz > immer noch nicht OK > 48MHz > sehr sporadisch nicht OK Darf man wissen um welchen I2C Slave/welches Projekt es sich handelt und welche Programmiersprache zum Einsatz kommt? Ich frage deshalb, weil mir bislang kein I2C Device untergekommen ist welches ein AVR nicht problemlos handeln konnte ?!
Ein Ersatz für den SAA1064. C / Keil. Das ganze durfte auch nicht größer und höher sein als der alte SAA1064, da dies als 1:1 Ersatz verwendet wird (incl aller Bauteile, Spannungsregler usw.).
:
Bearbeitet durch User
Markus M. schrieb: > Ein Ersatz für den SAA1064 Danke. Mit einem AVR gibts natürlich zahlreiche Möglichkeiten, ein paar 7-Segmentanzeigen o.ä. problemlos anzusteuern. Wenn man den ARM beherrscht wird man in spezielleren Fällen aber sicherlich dank mehr Speed noch flexibler bzw. kommt ggf. ohne zusätzliche Hardware aus.
Naja, ein plug-kompatibler Ersatz einer existierenden Hardware durch einen Controller ist immer keine ganz einfache Aufgabe. Die Hardware erledigt ihre Aufgabe einfach mal rasant schnell, weil sie alles parallel ausführen kann. Allerdings ist I²C an sich bezüglich des Timings ja eher gutmütig, wenn man Controller als Slave hat, da der Slave das Timing verlängern darf. (Bei SPI als Slave geht das nicht.) Wenn man das allerdings nicht machen möchte, weil man eben plug-kompatibel sein muss, dann entsteht die eigentliche Herausforderung. Hat ber mit dem Thema dieses Threads, bei dem es ja um den Einstieg für Anfänger geht, nicht so recht was zu tun.
oleg schrieb: > auf dieser Seite die Artikel über AVR und ARM Einstieg mit einem kleinen ARM im DIP-Package auf Steckbrett ist einfacher als mit AVR: keine zusätzliche Ausstattung erforderlich wie Programmer etc. Dazu gibt es auf "dieser Seite" aber keinen vernünftigen Artikel, sondern z.B. hier: https://learn.adafruit.com/getting-started-with-the-lpc810/programming-the-lpc810-with-flash-magic https://learn.adafruit.com/getting-started-with-the-lpc810/blinky
Beitrag #4953082 wurde von einem Moderator gelöscht.
Ich würde auch auf jeden Fall zum einem Arduino raten! Günstig, guter Support, große Community :)
ASM Superprofi schrieb im Beitrag #4953082: > Jörg W. schrieb: >> ASM Superprofi schrieb: >>> Ich empfehle ganz klar den ATtiny13A. >> >> Du hast die Ironie-Tags vergessen. > > Nein. Bei 1k Flash und 64Byte RAM kommt man sehr schnell an dessen Grenze. Der verwendet den RAM auch als Stack ... Ohje ohje ... Etwas größer sollte das ganze schon sein, dass man auch sinnvolle Sachen machen kann und nicht schon zum Code optimieren anfangen muss, bevor man irgendetwas zustande gebracht hat :)
:
Bearbeitet durch User
ASM Superprofi schrieb im Beitrag #4953082: >>> Ich empfehle ganz klar den ATtiny13A. >> Du hast die Ironie-Tags vergessen. > > Nein. Dann geh' bitte zurück ins vorige Jahrtausend. Das genügt für dich. Es verhindert auch, dass du denjenigen, die im 21. Jahrhundert mit Controllern anfangen, unsinnige Ratschläge erteilst. Sicher hat auch ein ATtiny13 seine Berechtigung, aber abseits von Masochismus nur dort, wo man wirklich mit jedem Cent sparen muss. Bei Einzelstücken (und das ist beim Bastler immer der Fall) muss man das praktisch nie.
Beitrag #4953128 wurde von einem Moderator gelöscht.
Ich würde zum STM32, SAM3/4 oder LPC17xx greifen. Besonders ST schmeisst mit Demo Boards nur so um sich, und ein ST-Link ist bereits mit auf dem Board. Der läuft dann mit den Demoversionen von Keil µVision bzw. IAR, sowie mit div. freien Toolchains. Sicherlich ist der Einstieg etwas schwiriger, aber man lernt einen Industrie-Standard kennen.
Random .. schrieb: > Besonders ST schmeisst mit Demo Boards nur so um sich Das ist ja nun kein wirkliches Argument, wenn es um das mentale Durchdringen des gesamten Mikrocontroller-Zirkusses für einen Anfänger geht. Der Arduino, so ungeliebt er bei manchem ist, der sich hier als „Profi“ fühlt, ist wohl bezüglich des Einstiegswiderstands wirklich kaum zu schlagen. Man hat nach dem Einstieg dann immer noch die Wahl, ob man weiter in die Tiefen der Hardware vordringen möchte (und das Framework beiseite lässt), oder ob einem das damit bereits vorgegebene Abstraktionsniveau genügt, und man sich lieber ans schnelle Lösen von Problemen macht. p.s.: > SAM3/4 Die halte ich für reichlich anfängerunfreundlich. Die Peripherals sind oft dinosaurierhaft überfrachtet, das Pinout graust die Sau. Atmels neuere ARMs (SAMD21 & Co.) machen da einen deutlich weniger angestaubten Eindruck.
:
Bearbeitet durch Moderator
Beitrag #4953184 wurde von einem Moderator gelöscht.
Beitrag #4953191 wurde von einem Moderator gelöscht.
Man muss halt differenzieren, was das persönliche Ziel ist. 1. Die Hardware "mastern", also hinterher sagen zu können "Hey, ich hab das Teil komplett verstanden", also sagen zu dürfen, dass der Berg bestiegen wurde. Das geht halt besser, wenn der Berg nicht allzuhoch ist. Und wenn das Argument "Peripherie überspringen" eines wäre, könnte man auch direkt zu ARM gehen. 2. So schnell wie möglich Projekt xy realisieren, Hintergrundwissen bitte nur das nötigste. Dann ist wirklich der Arduino das Mittel der Wahl.
ASM Superprofi schrieb: > "Hey, ich hab das Teil komplett verstanden" Naja. Das letzte System, bei dem man noch jedes Byte auswendig kannte, war wohl CP/M. Seither hat sich die Welt um mehrere Jahrzehnte gedreht, und es ist auch überhaupt nicht mehr notwendig, nun wirklich jedes Byte zu kennen. Dass man von den angebotenen Features für ein konkretes Projekt oft nur 20 % benutzt, ist nicht wirklich ein Manko. Wenn man sich aber die UART in Software zusammenstottern muss, während es für praktisch das gleiche Geld sowas alles fix und fertig in Hardware gibt, dann bleibt einem für die Software-Lösung wirklich nur das Wort „Masochismus“ übrig. Und eine UART für ein paar Debugausgaben ist ja nun wirklich nichts, was völlig aus der Welt gegriffen ist.
ASM Superprofi schrieb im Beitrag #4952938:
> Ich empfehle ganz klar den ATtiny13A.
Eher nicht. Als Anfänger hat man damit das Problem der Mehrfachnutzung
der ISP-Pins.
Daher ist der ATmega328P deutlich besser geeignet. Da kann man erstmal
die ISP-Pins exklusiv lassen. Und DIP-28 ist auch nicht riesig.
Oder gleich im DIP-40 den ATmega1284P.
Gerade als Anfänger macht man gerne Schaltungsfehler oder läßt sogar was
abrauchen. Da ist dann eine Rasterplatine mit DIP-Fassung extrem
praktisch. Zum SMD-Löten/-Entlöten braucht man schon etwas Erfahrung und
gutes (teures) Werkzeug.
ASM Superprofi schrieb: > 2. So schnell wie möglich Projekt xy realisieren, Hintergrundwissen > bitte nur das nötigste. Dann ist wirklich der Arduino das Mittel der > Wahl. Naajaa ... Das hab ich jetzt erst mit dem STM32F1 so gemacht ... Mein Projekt hab ich - sozusagen - zusammen gegoogelt ... Entweder von CubeMX generieren lassen (wie USB und die PLL, ...) und dann quasi mit Hardware-Schnippsel aus Tutorials aufgefüllt und angepasst ... Ich bin fast vollständig ohne Datenblatt ausgekommen ... Das geht also ;-) Allerdings muss man wissen, was man für Peripherie hat und was man sich für eine Funktion davon erwartet ... Wie z.B. der µC hat mehrere Timer und über mehrere Pins lassen sich PWM-Waveforms generieren. Dann googelt man gezielt danach und ist fast fertig, ohne über die Hardware auf Register-Ebene überhaupt was wissen zu müssen :)
Mampf F. schrieb: > Dann googelt man gezielt danach und ist fast fertig, ohne über die > Hardware auf Register-Ebene überhaupt was wissen zu müssen Das ist ja wahrscheinlich genau das, was unser „Superprofi“ (ob der damit wirklich sein Geld verdient?) nun wohl nicht möchte. Wäre aber beim Arduino kaum anders, auch da muss man ja die Hardware nicht auf Registerebene verstehen.
>Wäre aber beim Arduino kaum anders, auch da muss man ja die Hardware >nicht auf Registerebene verstehen. Arduino ... das Stichwort ... Ich bastle grad mit dem STM32F103 und zwar mit der Arduino IDE. Für den STM32F103 gibt es ziemlich viele Anleitungen im Netz. http://grauonline.de/wordpress/?page_id=1004 Mit diesem Youtube Video ging es auf Anhieb: https://www.youtube.com/watch?v=Ze6q6NidS5w Die STM32F103 BluePill Boards http://wiki.stm32duino.com/index.php?title=Blue_Pill hat vor kurzem ein Kollege für unter 2Euro in China erstanden.
ASM Superprofi schrieb: > Die Hardware "mastern", also hinterher sagen zu können "Hey, ich hab > das Teil komplett verstanden" Das ist eigentlich langfristig gesehen mein Ziel. Für den Anfang wäre es nett ohne extremen Aufwand ein paar LEDs blinken zu lassen, Taster einzulesen, Servos anzusteuern. Wenn ich die Meinungen hier so lese, gibt es eigentlich kein echtes KO-Kriterium als Anfänger mit einem ARM zu beginnen, also würde ich mich näher damit beschäftigen. ARM: ---- Ich bin auf zwei Tutorials gestoßen die sich mit einem Evalboard STM32VL beschäftigen, das eine (http://www.diller-technologies.de/stm32.html) legt eine Art Standard-Library zugrunde und das andere (http://en.radzio.dxp.pl/stm32vldiscovery/) arbeitet rein auf Basis des Datenblattes (er nennt es Reference Manual). Was ist denn jetzt die bessere Herangehensweise? ATMEL/PIC: ---------- Die Quellcodes sind teilweise schon deutlich kleiner als bei den ARMs, ich beziehe mich hier aber nur auf das einschalten einer LED, ist aber eine reine Anfängerbeurteilung.
oleg schrieb: > aber nur auf das einschalten einer LED Bei den AVRs ist es simpel ein
1 | void main() {
|
2 | DDRA |= 0x01; |
3 | PORTA |= 0x01; |
4 | } |
dann leuchtet die LED schon. Bei den ARMs kommt noch sehr viel Brimborium außen rum ... Die haben halt unendlich mehr Features und alleine, bis man die Hardware initialisiert hat, sind einige Zeilen Code notwendig. Aber wie gemeint ... Evtl einfach ein Maple Mini oder ein Blue Pill Board mit STM32F1 zB kaufen und Tutorials durchackern. Ein großer Vorteil - können die AVRs auch? - ist das Debuggen. Beim STM32 installiert man sich Eclipse + Gnu-ARM-Plugin + ARM-GCC-Toolchain + OpenOCD und dann man kann in Eclipse C/C++ Code schreiben (man kann sich ein LED-Blink-Demo für zB STM32F1 generieren lassen), dann funktionier das meiste out-of-the-box. Und der Debugger (Hardware-Breakepoints oder Single-Step zB) in Eclipse funktioniert auch direkt. Das ist schon sehr nett :) Als Debugger entweder einen 3EUR STLinkV2 USB-Adapter (funktioniert unter Linux super) oder gleich das STM32F4-Discovery-Board (das hat den STLinkV2 schon on-Board) und los gehts :) Ich hatte damals (vor 2 Jahren, aber dann nichts mehr damit gemacht) mir das STM32F4-Discovery gekauft und von Null bis zum LED-Blinken hat es genau 45min gedauert :)
:
Bearbeitet durch User
Beitrag #4953267 wurde von einem Moderator gelöscht.
oleg schrieb: > Die Quellcodes sind teilweise schon deutlich kleiner als bei den ARMs Yep, das ist das, was ich meinte: du musst dich beim ARM erstmal einigermaßen intensiv darum kümmern, die CPU überhaupt „auf Trab“ zu bringen. Auch ein simples Delay, wie man es für die allererste blinkende LED nun mal vorzugsweise nimmt, damit man nicht auch gleich noch die Bedienung eines Timers erlernen muss, ist auf dem ARM nicht so ganz trivial. Je nach Core, Cache etc. ist es nicht mehr so geradlinig berechenbar, wie lange man die CPU um einen Countdown herumkreisen lassen muss, damit sie eine definierbare Zeit vertrödelt. Der AVR ist dahingehend völlig geradlinig: der Zeitbedarf jeder Instruction ist sehr einfach ermittelbar, und es gibt in der Bibliothek die Bequemlichkeitsfunktionen _delay_us() und _delay_ms(), damit man das Ausrechnen der CPU-Zyklen dem Compiler überlassen kann.
Mampf F. schrieb: > Ein großer Vorteil - können die AVRs auch? - ist das Debuggen. Ja, können sie auch, allerdings sind die Tools paar Groschen teurer, und das eigentliche Debugprotokoll ist proprietär. Es gibt aber inzwischen auch da fix und fertige Boards mit Onboard-Debugtools (Xplained Mini). Allerdings gibt es vermutlich dafür nicht so viele China-Cloner. Der normale Arduino (der nun wieder massenhaft geclonet wird) hat keinen Debugger an Bord.
Jörg W. schrieb: > Der normale Arduino (der nun wieder massenhaft > geclonet wird) hat keinen Debugger an Bord. Das ist allerdings schade ... Gerade beim Debuggen der empfangenen IR-Fernbedienungs-Codes über meinen IR-Empfänger war das Gold wert :) Und bei ARM benötigt man nur 2 Port-Pins + Reset :) Der ARM sollte eigentlich egal sein, wenn ich richtig informiert bin ... STM32 sind nur derzeit hmm beliebt :)
Beitrag #4953282 wurde von einem Moderator gelöscht.
Beitrag #4953293 wurde von einem Moderator gelöscht.
> Einstieg mit einem kleinen ARM im DIP-Package auf Steckbrett DIR0_bit.P0_0 = 1; PIN0_bit.P0_0 = 1; Also mehr "simpel" als bei AVR: Mampf F. schrieb: > Bei den AVRs ist es simpel ein > void main() { > DDRA |= 0x01; > PORTA |= 0x01; > } > > dann leuchtet die LED schon. > > Bei den ARMs kommt noch sehr viel Brimborium außen rum
Beitrag #4953323 wurde von einem Moderator gelöscht.
Beitrag #4953341 wurde von einem Moderator gelöscht.
Mampf F. schrieb: > Das ist allerdings schade ... Gerade beim Debuggen der empfangenen > IR-Fernbedienungs-Codes über meinen IR-Empfänger war das Gold wert :) Was soll da ein Debugger helfen. Du setzt einen Breakpoint und dann? Nimm einfach IRMP.
Beitrag #4953355 wurde von einem Moderator gelöscht.
Markus M. schrieb: > Manchmal denkt man es ist nur eine triviale Aufgabe Du brauchst 48MHz um einen I2C zu betreiben? Das ist nicht dein Ernst oder? Der muss wahrscheinlich sonst auch nicht viel tun sonst wärest du nicht mit 8MHz angefangen. Auf einem AVR wäre es evtl. einfacher gewesen. Aber es ist halt cool wenn man behaupten kann, man beherrscht einen Arm. Deshalb wird den armen Anfängern hier immer wieder ein ARM empfohlen. Ich kann Jörg nur beipflichten: Jörg W. schrieb: > Ein AVR braucht weniger „Brimborium Als Anfänger braucht keiner einen ARM, da liegen die Prioritäten einfach woanders.
900ss D. schrieb: > Du brauchst 48MHz um einen I2C zu betreiben? Nee, sondern um ein Gerät zu emulieren, welches ansonsten viele Aktionen in Hardware parallel erledigt, die man in Software serialisieren muss. Ich würde mal sagen, er hat sich wohl da nicht gerade glücklich ausgedrückt, um diesen Thread hier nicht zu sehr vom Thema abwandern zu lassen. Der Kern seiner Aussage ist doch, dass zuweilen eine anfangs einfach erscheinende Aufgabe in der Realität dann doch unerwartete Schwierigkeiten aufweisen kann – ich glaube, dieser Grundaussage wird hier so ziemlich jeder zustimmen können. ;-)
Peter D. schrieb: > Mampf F. schrieb: >> Das ist allerdings schade ... Gerade beim Debuggen der empfangenen >> IR-Fernbedienungs-Codes über meinen IR-Empfänger war das Gold wert :) > > Was soll da ein Debugger helfen. Du setzt einen Breakpoint und dann? Dann kann ich in meiner Variable sehen, was IRMP empfangen hat ... Insbesondere bei unbekannten Fernbedienungen und wenn ansonsten keine Schnittstelle zur Außenwelt existiert. > Nimm einfach IRMP. Been there, done that. So exotisch war jetzt die Idee mit dem Breakpoint aber nicht, dass man nicht von selbst drauf kommen hätte können ;-)
:
Bearbeitet durch User
Beitrag #4953399 wurde von einem Moderator gelöscht.
oleg schrieb: > Ich will mich damit > Hobbymäßig beschäftigen. Was könnt ihr aus eurer Erfahrung heraus > empfehlen? Du kommst bei Deinen Schaltungen mit max. 3,3 V aus und hast keine Probleme bei einem µC-Defekt ein 64-144 pol. TQFP Gehäuse auszulöten und zu ersetzen? Dann fange mit ARM an. Du möchtest mit Spannungen bis 5 V arbeiten, brauchst nicht höchste Geschwindigkeit und bevorzugst, im Fehlerfall einen 28-40 pol. µC im DIP-Gehäuse auszuhebeln und einen neuen in die Fassung zu stecken? Mein Rat: ATMega328. Meinetwegen auch in Form eines Arduino UNO. Du kannst Dich garnicht entscheiden? Nimm ein STM32Fxxx-Nucleo Board und einen Arduino UNO. Dann siehst Du ganz schnell, wo Deine persönlichen Vorzüge liegen, bzw. welcher µC zuerst das macht, was DU möchtest ;-)
Wenn du noch nicht weisst, wo deine Basteleien enden sollen, dann fang mit einem 8bit ATtiny13 und ein Arduino Nano (clone) mit ATmega328P an. Beide passen in ein Steckbrett. Beide haben den gleichen Befehlssatz. Der Atmega funktioniert prinzipiell genau so, hat aber mehr Funktionen und mehr Pins. Beide sind sehr gut dokumentiert. Der "nackte" ATtiny muss mit einem ISP Programmieradapter programmiert werden. Das Arduino Nano Modul enthält ein USB Interface und einen Bootloader, kann jedoch alternativ ebenfalls über den ISP Anschluss programmiert werden. Es gibt noch etwas größere AVR Mikrocontroller, die sind allerdings teurer. Bei größeren Anwendungsfällen solltest Du Dir besser 32bit ARM basierte Controller anschauen, denn da gibt es viel mehr Spielraum nach oben Speicher, Leistung, Funktionsumfang). Für den Anfang rate ich allerdings zu ATtiny und ATmega, weil sie leichter zu erlernen sind und offensichtlich bereits weit mehr können, als du momentan brauchst. Falls du später irgendwann Videos verarbeiten willst, oder irgendwas anderes leistungshungriges, kannst du immer noch auch ARM wechseln.
Hallo, m.n. schrieb: > Du kommst bei Deinen Schaltungen mit max. 3,3 V aus und hast keine > Probleme bei einem µC-Defekt ein 64-144 pol. TQFP Gehäuse auszulöten und > zu ersetzen? > Dann fange mit ARM an. Naja, es gibt ja auch so was wie den LPC1114/201 im DIP28 und die Peripherie ist nicht komplizierter als bei einem AVR. Beispiele zu dem Teil findet man auch genug im Netz, also den bekommt man mit Sicherheit genauso schnell zu laufen wie einen ATmega328. Also wenn ich jemanden einen Anfängerprozessor empfehlen sollte, dann den. Ich verstehe auch die Probleme nicht, die manche hier scheinbar mit der Initialisierung eines STM32x haben. STM32CubeMx generiert diese Initialisierung einmal und dann kann man das in alle Projekte (mit dem gleichen µC/Setup) kopieren, auch wenn man vom STM32CubeMx nichts hält und die Peripherie-Register lieber von Hand bespaßt. Das Schöne an den ganzen STM32x ist aber, dass man von ganz klein (z.b. STM32F030F4), bis zu fetten Teil STM32F4xx vieles wieder verwendbar ist. Und an die Assembler-Fraktion hier: Lieber den ARM in Assembler programmieren, als einen AVR. BG, Tom
Markus M. schrieb: > Arduino - große Comunity und viel im Internet. Für den Einstieg ohne > viel Ahnung sehr gut. > > Nach den ersten Versuchen und etwas Erfahrung empfehle ich recht schnell > den Wechsel zum ARM Der Arduino Due hat einen ARM Prozessor ;-)
oleg schrieb: > Ich will mich damit > Hobbymäßig beschäftigen. Was könnt ihr aus eurer Erfahrung heraus > empfehlen? Als allererstes empfehle ich dir ein Blatt Papier, wo du dir selbst mal nach kritischem Nachdenken draufschreibst, womit GENAU du dich beschäftigen willst. "Beschäftigen" klingt mir nach Zeit totschlagen - aber das wird es ja wohl nicht sein. Deshalb mal ein paar Fragen meinerseits: 1. Willst du in deiner Freizeit irgendwas bauen? Also derart, daß zum Schluß eine Kiste mit nützlicher Funktion herauskommt? 1a. Was schwebt dir da so vor? 1b. Wenn nix, dann was willst du dann mit einem µC anfangen? 2. Willst du beim Programmieren für µC geeignete Algorithmen, Herangehensweisen, Strukturen lernen? Oder eher nur sehen, daß auf dem Steckbrett irgendwas wackelt oder blinkt? 3. Wieviel Zeit und Aufmerksamkeit willst du dem Hobby geben? Willst du zuvor dir Kenntnisse über die HW anlesen oder soll irgendwas möglichst gleich aus der Box wackeln&blinken? 4. Grundlagen in C hast du, wie siehts's mit dem sonstigen Horizont aus? Applikationen per Pascal (Delphi, Lazarus) auf dem PC? Und hast du Berührungsängste vor Assembler oder nicht? 5. Wie gut sind deine Kenntnisse in Hardware, also Schaltungstechnik analog wie digital? 6. Wie gut sind deine Fertigkeiten im Leiterplatten entwerfen? 7. Wieviel Geld willst du ins Hobby stecken? Ich sag's mal so: Wenn du keine Scheu hast, die Nase in die Manuals zu stecken und dich direktemang mit dem Chip deiner Wahl und dessen innerer Struktur vertraut zu machen, dann empfehle ich dir als jemand, der mit C angefangen hat, allemal einen Cortex. Die Dinger sind erheblich leistungsfähiger als alles Achtbittige zuvor. Beim Kaufpreis scheiden sich die Geister, deswegen empfehle ich dir einen Cortex M4F (mit 'F'!) wenn ein Chip-Preis von rund 10 Euro dich nicht schreckt. Ansonsten wäre meine Empfehlung ein Cortex M3, die gibt es per Ebay schon für etwa 1.10 Euro oder auf Mini-LP für rund 2 Euro. Zu Herstellern: Die LPC-Typen von NXP und die STM32F-typen von ST sind hardwaremäßig OK und auch die Dokumentationen dazu sind ordentlich les- und verstehbar. Obendrein haben beide einen residenten Bootlader intus, was die Frage nach dem Programmer gar sehr vereinfacht. Beide Typenreihen sind also m.E. empfehlenswert. NXP vertreibt auch die Kinetis µC von Freescale, die sind regelmäßig etwas billiger als die LPC und STM, aber die Kinetis und ihre Dokumentation mißfallen mir. Ansonsten bleibt noch Nuvoton, die haben neuerdings einen Internetshop. Deren µC haben keinen Bootlader, brauchen also ein JTAG/SWD-Geschirre. Dafür sind sie relativ billig, aber auch ein wenig bieder - was nicht stören sollte. Ob ein µC nun 100 MHz kann oder "nur" 72 MHz, ist meistens egal. Die Dokumentation von Nuvoton ist zwar chinesisch gedacht, aber ordentlich und gut lesbar. Also, bevor du eine Wahl triffst, lade dir die Manuals von diversen Herstellern und steck die Nase hinein, um zu sehen, welche dir gefallen. Jetzt noch mit Atmel AVR und so anfangen zu wollen, halte ich für schlichtweg verkehrt. Jaja, da gibt es Fans, aber die haben schon seit vielen Jahren ihr Geschirre von Toolchain, Programmer und Boards in der Bastel-Schublade - du hingegen nicht. Und jetzt noch das Zeugs anzuschaffen.. ach nö. W.S.
Beitrag #4953694 wurde von einem Moderator gelöscht.
oleg schrieb: > Das ist eigentlich langfristig gesehen mein Ziel. Für den Anfang wäre es > nett ohne extremen Aufwand ein paar LEDs blinken zu lassen, Taster > einzulesen, Servos anzusteuern. Zum reinschnuppern eignet sich der Arduino-Kram durchaus. Für den Anfang ist es auch fast komplett egal ob da jetzt ein ATMega, ein STM32 oder ein ESP8266 im Hintergrund werkelt. Die von dir genannten Sachen lassen sich damit durchaus bewerkstelligen und wie schon zuvor genannt gibt es endlos viele Beispiele. oleg schrieb: > Wenn ich die Meinungen hier so lese, > gibt es eigentlich kein echtes KO-Kriterium als Anfänger mit einem ARM > zu beginnen, also würde ich mich näher damit beschäftigen. Nein, ein wirkliches KO-Kriterium gibt es nicht. Die ARM-Controller können halt deutlich mehr als die ATMegas und PICs und sehen dementsprechend erstmal sehr kompliziert aus. Man ist aber nicht gezwungen das alles zu nutzen. Entgegen aller Unkenrufe gibt es durchaus ARM-Controller, die 5V-kompatibel sind, als auch handliche Boards wie z.B. die Bluepill oder Maple-Mini mit STM32. Beide kannst du verwenden wie einen 40-Pin ATMega, mit dem Unterschied, dass bei denen noch ein paar andere Dinge auf der Platine verbaut sind (Quarz, Spannungsregler, etc.). Geht dir der Controller hops, dann tauschst du halt das ganze Board. Die Blue-Pill Boards gibt es beim Chinamann für unter 2€ und wenn du willst kannst du die auch per Arduino programmieren (wie auch die Maple-Minis). oleg schrieb: > ARM: > ---- > Ich bin auf zwei Tutorials gestoßen die sich mit einem Evalboard STM32VL > beschäftigen, das eine (http://www.diller-technologies.de/stm32.html) > legt eine Art Standard-Library zugrunde und das andere > (http://en.radzio.dxp.pl/stm32vldiscovery/) arbeitet rein auf Basis des > Datenblattes (er nennt es Reference Manual). Was ist denn jetzt die > bessere Herangehensweise? Die Standard Peripheral Library war eine Bibliothek von ST zur Programmierung von STM32. Mittlerweile wird sie aber nicht mehr weiterentwickelt und wurde durch eine andere Bibliothek (STM32 HAL) abgelöst. Das Reference-Manual ist das eigentliche Herzstück der Dokumentation. Meistens ist es für mehrere Mikrocontroller in einer Familie zusammengefasst. Hier steht drin welche Register es gibt und was man damit bewerkstelligen kann. Das Datenblatt ist eher spezifisch für einzelne Mikrocontroller. Hier findest du z.B. Pinouts oder auch das Memory-Layout (für einen bestimmten Controller). Welche Herangehensweise jetzt besser oder schlechter ist, darüber lässt sich vortrefflich streiten (was hier in diesem Forum auch gern und viel getan wird). Ich persönlich würde direkt den Weg vom Arduino zum Lesen und Schreiben einzelner Register wählen und zwar ganz egal ob mit Atmel oder ARM. Der Vorteil ist der, dass du das beides (Arduino und Register) wunderbar miteinander mischen kannst wenn du denn weißt was du tust. Gerade für den Anfang ist das aber eher zäh und hat ein beträchtliches Frustpotential. Demgegenüber hat man halt sehr viel mehr Möglichkeiten, wenn man sich mit der Programmierung auf Registerebene auskennt. Was Hardware angeht sind die Nucleo Boards sehr komfortabel, weil der Debugger schon auf dem Board ist. Ich würde jedoch für kleine Projekte immer Boards vom Formfaktor eines Arduino Nano oder Blue-Pill bzw. Maple-Mini gegenüber einem Nucleo-Board bevorzugen, weil die nicht nur günstiger sind, sondern sich auch schlichtweg viel einfacher (und kompakter) auf einer Lochrasterplatine verbauen lassen. Auf den Nucleo-Boards ist ein Debugger bereits an Board aber ein externer ST-Link Clone tut es auch. Ich würde auch unbedingt noch so einen 8-Kanal 24MHz Logic Analyzer als Werkzeug empfehlen. Der kostet beim Chinamann gerade mal 5€ und ist jeden Cent Wert wenn man mal gucken will ob an dem Pin jetzt eigentlich das raus kommt, was man erwartet bzw. ob überhaupt etwas raus kommt und wie das in etwa aussieht.
Tom schrieb: > STM32CubeMx generiert diese > Initialisierung einmal Das hat dafür andere Eselsohren, über die ein Anfänger nicht so einfach hinweg kommt ... STM32CubeMX verwendet den Hardware-Abstraction-Layer (HAL) von ST und der ist quasi nicht kompatibel mit den tausenden Tutorials, die man im Internet für die STM32 findet. Die verwenden alle die Standard-Library CMSIS. Ich hatte selbst die Freue, funktionierenden CMSIS Code nach HAL zu portieren, weil ich sonst mein USB nicht in Gang bekommen hätte. Geht schon, ist aber schlecht dokumentiert und verwendet (noch?) kaum jemand.
@mampf F.: Ja, da gebe ich dir Recht, eigentlich ist das ein ziemliches Machwerk. Mir ging es in dem Zusammenhang auch nur um das Einsteigen. Wenn man dann mal durch-stept, versteht man schon was gemacht werden muss. @wutz: Klar, sehe ich auch so, aber auch beim ARM schaue ich mir den kompilierten Kode bei zeitkritischen Sachen mal an. Und wenn man wirklich mal ran muss, dann wie gesagt lieber ARM. BG, Tom
Beitrag #4953745 wurde von einem Moderator gelöscht.
Tom schrieb: > Ja, da gebe ich dir Recht, eigentlich ist das ein ziemliches Machwerk. > Mir ging es in dem Zusammenhang auch nur um das Einsteigen. Da finde ich die "Start"-Projekte gut, die das Eclipse-ARM-Plugin erzeugen kann :) Funktioniert super out-of-the-box (z.B. "Blinky") und kommt ohne HAL aus. Dann kann man auch besser mit den Tutorials arbeiten :) Aber USB kriegt man halt ohne HAL kaum zum Laufen (ich zumindest^^)
Fuchs schrieb im Beitrag #4953745: > Einfach mal den Umfang der Datenblätter > miteinander vergleichen STM32F1 ist noch ein einer der kleinen Controller und sein Datenblatt hat ~1200 Seiten xD
Wie immer, aller Anfang ist schwer. Hier eine Schritt-für-Schritt Anleitung wenn man zum ersten mal ein STM32 auf einem STM32F4DISCOVERY Board bespielt: STM32 CooCox Installation Kosten: ca. 20€ für das STM32F4DISCOVERY Board.
Markus M. schrieb: > Wie immer, aller Anfang ist schwer. Hier eine Schritt-für-Schritt > Anleitung wenn man zum ersten mal ein STM32 auf einem STM32F4DISCOVERY > Board bespielt: > > STM32 CooCox Installation > > Kosten: ca. 20€ für das STM32F4DISCOVERY Board. Coocox ist ganz okay, aber obsolet. Ich kann EMBitz als Alternative wärmstens empfehlen.
Die kleinen Freescale Kinetis ARMs (MKL0xxx, MKE0xxx) sind auch ganz nett, extrem einfach gestrickt, kaum nennenswert komplizierter zu handhaben als ein AVR ATMega aber wesentlich mehr Dampf unter der Haube und kosten nur ein Bruchteil davon. Demo-Boards gibts auch für kleines Geld, Toolchain und IDE kostenlos (frei) und auch auf dem heimischen Linux-Rechner ohne Einbußen oder Verrenkungen zu programmieren und zu debuggen (wie eigentlich fast alle ARMs).
Markus M. schrieb: > Wie immer, aller Anfang ist schwer. Hier eine Schritt-für-Schritt > Anleitung wenn man zum ersten mal ein STM32 auf einem STM32F4DISCOVERY > Board bespielt: > > STM32 CooCox Installation Warum CooCox nehmen, wenn man "deren" AC6 System Workbench benutzen könnte. Es hat den Vorteil, dass man sich die Orgie mit Eclipse und veraltete Anleitungen zur Installation von verschiedenen Plugins erspart. Unter anderem ist CooCox recht langsam. Wenn man Stm32 F0 oder L0 Mikrocontroller nimmt, kann auch Keil IDE ohne Code-Einschränkung verwenden. http://www2.keil.com/stmicroelectronics-stm32/mdk EDIT: Apropos Demo Board: Beitrag "[V]erschenke TI Gutscheine"
:
Bearbeitet durch User
Und wieder mal die alte Leier: jeder gibt gute Ratschläge was das beste ist - die IDE ist gut bzw. muss vermieden werden - die CPU ist genau richtig für dich bzw. damit kannst du nix anfangen - dein Projekt entscheidet bzw. das passt nicht zum Projekt - lies dich erst mal kommplett ins Thema ein bevor du anfängst/fragst So lange man eine CPU wählt, die der Hersteller noch unterstützt, ist die konkrete Entscheidung völlig egal für den Lernerfolg. Es fehlt komplett an konkreter Hilfestellung. Benötigt würde ein Angebot wie, wo wohnst du, da ist der Club wo ich auch zu finden bin, komm vorbei ich zeige dir die ersten Schritte. Später gebe ich dir noch Hilfe bei akuten Problemen für schnellere Fortschritte. Das macht für den Helfenden Arbeit und dazu hat keiner Lust. Lieber unter Gleichgesinnten etwas Fachsimpeln und die eigene Kompetenz zur Schau stellen. Und später, wenn der "Neue" sich selbst genug Erfahrung hart erarbeitet hat, macht er es genau so, ganz nach dem Motto "warum soll es anderen besser ergehen wie mir". Das macht Elektronik/Informatik zu einem Hobby für Einzelgänger.
Beitrag #4953889 wurde von einem Moderator gelöscht.
W.S. schrieb: > Jetzt noch mit Atmel AVR und so anfangen zu wollen, halte ich für > schlichtweg verkehrt. Du hast doch noch nie etwas mit AVRs gemacht. Ich habe mir gerade mal wieder welche bestellt - STM32Fxxx kaufe ich auch ;-) W.S. schrieb: > Ansonsten wäre > meine Empfehlung ein Cortex M3, die gibt es per Ebay schon für etwa 1.10 > Euro oder auf Mini-LP für rund 2 Euro. Das Preisargument mit billigem China-Kram finde ich das Allerletzte. Für einen Anfänger zählt vielmehr, daß in überschaubarer Zeit Erfolgserlebnisse erzielt werden. Tom schrieb: > Naja, es gibt ja auch so was wie den LPC1114/201 im DIP28 und die > Peripherie ist nicht komplizierter als bei einem AVR. Ein schönes, großes Krabbeltier. Ist ja nicht schlecht, aber bei 5 V Versorgungsspannung zieht es seine Beine ein.
a story eternally retold schrieb: > So lange man eine CPU wählt, die der Hersteller noch unterstützt, ist > die konkrete Entscheidung völlig egal für den Lernerfolg. Bullshit. Wenn ich mit Assembler auf einem CDP1802 (der wird auch heute noch verwendet) anfange, dann dauert es ewig, bis ich erste Ergebisse habe. Es gibt viele einfacher zu programmierende 8-bit µCs... Wenn ich mit einem OpenSparc als Softcore anfange, brauche ich (ohne größere Vorkentnisse) Monate bis alles so funktioniert wie es soll. Teuer ist es (genauer: die erforderliche Hardware) obendrein auch noch... Wenn ich mit einem Arduino anfange, dann läuft das erste Programm (inklusive Hardware auf Steckbrett) nach einer Stunde, ich habe guten Support in Foren und unzählige Tutorials. Konkurenzlos günstig ist es obendrein auch noch. Was will man als Anfänger mehr? a story eternally retold schrieb: > Es fehlt komplett an konkreter Hilfestellung. Benötigt würde ein Angebot > wie, wo wohnst du, da ist der Club wo ich auch zu finden bin, komm > vorbei ich zeige dir die ersten Schritte. Später gebe ich dir noch Hilfe > bei akuten Problemen für schnellere Fortschritte. Das macht für den > Helfenden Arbeit und dazu hat keiner Lust. Lieber unter Gleichgesinnten > etwas Fachsimpeln und die eigene Kompetenz zur Schau stellen. Und > später, wenn der "Neue" sich selbst genug Erfahrung hart erarbeitet hat, > macht er es genau so, ganz nach dem Motto "warum soll es anderen besser > ergehen wie mir". Die konkrete Hilfestellung lautet: Besorg dir ein Arduino, einen Sortimentskasten mit Bauteilen und ein gutes Online-Tutorial. Und dann leg los, bei Problemen kannst dich im Forum melden. Normalerweise braucht man hier keinen, der einem alles vorkaut. Versuch macht klug, und selbst wenn es Rauchzeichen gibt, dann kostet es nur ein paar Euro. Wenn ich gemeinsam Elektronik-Basteln will, kann ich zum örtlichen Amateurfunk-Ortsverband (ältere Generation) oder zum nächsten Hackerspace (jüngere Generation). Informatik gibts einige Orte weiter eine Gruppe des CCC. Es gibt also durchaus entsprechende Angebote. a story eternally retold schrieb: > Das macht Elektronik/Informatik zu einem Hobby für Einzelgänger. Ist halt so. Es gibt Bereiche, bei denen Treffen mit viel Zeitaufwand und wenig Nutzen verbunden sind. Was bringt es mir, wenn ich zum Basteln meine halbe Hobbywerkstatt mitschleppen muss und dafür das machen kann, was ich auch zu Hause machen kann? Vereine lohnen nur dann, wenn man irgendwas machen will, das man entweder alleine nicht vernünftig machen kann oder das enorme Investitionskosten erfordert. Fußball, zum Beispiel. Oder Segelfliegen. Oder Rudern. Oder Bergsteigen. Oder Schach spielen. Oder Boxen. Oder Sportschießen. Oder...
m.n. schrieb: > W.S. schrieb: >> Ansonsten wäre >> meine Empfehlung ein Cortex M3, die gibt es per Ebay schon für etwa 1.10 >> Euro oder auf Mini-LP für rund 2 Euro. > > Das Preisargument mit billigem China-Kram finde ich das Allerletzte. > Für einen Anfänger zählt vielmehr, daß in überschaubarer Zeit > Erfolgserlebnisse erzielt werden. Arduino-Nachbauten sind auch nicht teurer. Die gibts auch ab 2€/Stück. Für 30€ gibts ein großes Starterkit mit allem was man am Anfang halt so braucht. Vom eigentlichen Arduino über Steckbretter, unzählige Sensoren, LEDs, Widerstände, Servo, Schrittmotor... Wer will, kauft sich für 20€ aus China ein Roboter-komplett-Set und schon hat man etwas, das Linien folgen, Blumenvasen in der Wohnung suchen und umfahren oder die Katze erschrecken kann.
Beitrag #4954025 wurde von einem Moderator gelöscht.
Beitrag #4954028 wurde von einem Moderator gelöscht.
Beitrag #4954065 wurde von einem Moderator gelöscht.
Beitrag #4954071 wurde von einem Moderator gelöscht.
Ja, mit den AVRs hat man schon eine gute Grundlage: es gibt genug sehr preiswerte Hardware in Form von Arduino-Boards und mit dem avr-gcc einen sehr guten Compiler, außerdem viele Beispiele. Man muss die Hardware auch nicht unter Arduino betreiben, sondern kann direkt "nackt" mit C anfangen. Dafür gibt es hier im Forum auch schöne Artikel. AVR-Assembler kann man sich anschauen, ist aber fehlerträchtig, mühsam und für 99,9% der Projekte unnötig. Von der eventuellen späteren Portierung des Codes mal ganz abgesehen. Sinnvoll ist es aber, sich öfter mal die Assembler-Ausgaben des C-Compilers anzuschauen - dann bekommt man ein gutes Gefühl dafür, welche Konstrukte viel (Zeit/Speicher) "kosten" und wie hervorragend dieser optimiert. Die Frage ist auch, was Du mit "Hobbyprojekten" meinst :-) Mein neuestes Hobbyprojekt (elektronische Leitspindel, siehe: Beitrag "automatischer Vorschub für Drehbank") wäre so mit AVRs nicht mehr darstellbar, da dabei 8-Bitter einfach an ihre Grenzen stoßen. Daher fiel dort die Wahl auf STM32. Die Initialisierung dort ist sicherlich aufwändiger - allerdings bieten diese Controller auch deutlich mehr Möglichkeiten. Und die Initialisierung kann man sich ja heutzutage vollautomatisch generieren lassen. Weiterhin gibt es natürlich auch dafür Bibliotheken, die einem viel Arbeit abnehmen. Wenn Du also schon weisst, dass es komplexer werden könnte (bspw. wenn Du mal ein größeres Farb-LCD anschließen und flüssig betreiben möchtest), dann wäre eine direkte Einarbeitung in STM32 wohl sinnvoll, da letztendlich weniger Arbeit. Preislich tut sich das auch nicht viel und im Hobbybereich ist das sowieso egal. Die 3,3V/5V-Frage würde ich heutzutage nicht mehr als so wichtig anssehen. Praktisch alle Neuentwicklungen laufen problemlos (meist sogar nur noch) unter 3,3V und die meisten Pins der STM32 sind 5V-tolerant. Sehr preiswerte Entwicklungsboards gibt es auch für die STM32, auch im Steckbrettmaß von 2,54mm. Ein Kriterium für STM32 sind die sehr guten Debugmöglichkeiten ohne große Zusatzhardware. Also: entscheide selbst :-)
:
Bearbeitet durch Moderator
Chris D. schrieb: > Die 3,3V/5V-Frage würde ich heutzutage nicht mehr als so wichtig > anssehen. Manchmal hängt es garnicht vom persönlichen Geschmack ab, sondern davon, was extern vorgegeben wird. Wenn die Hintergrundbeleuchtung einer LC-Anzeige 5 V braucht, dann ist das schon wichtig. > Praktisch alle Neuentwicklungen laufen problemlos (meist sogar > nur noch) unter 3,3V und die meisten Pins der STM32 sind 5V-tolerant. Das nützt nur nichts, wenn man z.B. mobile Geräte direkt und sparsam aus einer LiIon-Zelle versorgen möchte. Bei AVR ist das kein Problem. Chris D. schrieb: > Also: entscheide selbst :-) Das kann er aber erst, wenn er Beides probiert hat ;-)
m.n. schrieb: > Chris D. schrieb: >> Die 3,3V/5V-Frage würde ich heutzutage nicht mehr als so wichtig >> anssehen. > > Manchmal hängt es garnicht vom persönlichen Geschmack ab, sondern davon, > was extern vorgegeben wird. Wenn die Hintergrundbeleuchtung einer > LC-Anzeige 5 V braucht, dann ist das schon wichtig. Ja, es gibt immer Ausnahmen - aber da ist ein zusätzlicher Spannungsregler auf dem Steckbrett nicht wirklich ein Problem. Was kostet ein LM317? 10ct? >> Praktisch alle Neuentwicklungen laufen problemlos (meist sogar >> nur noch) unter 3,3V und die meisten Pins der STM32 sind 5V-tolerant. > > Das nützt nur nichts, wenn man z.B. mobile Geräte direkt und sparsam aus > einer LiIon-Zelle versorgen möchte. Bei AVR ist das kein Problem. Ich sehe da auch bei den ARMs kein großes Problem. Die STM32F0 laufen ab 2V bis 3,6V. Wenn es sparsam sein soll würde ich aber sowieso mit Stepdown arbeiten. > Chris D. schrieb: >> Also: entscheide selbst :-) > > Das kann er aber erst, wenn er Beides probiert hat ;-) Natürlich :-) Wenn er aber sowieso schon weiss, dass er etwas mehr "Dampf" benötigt, dann erübrigt sich mMn die Einarbeitung in AVR. Die Zeit wäre dann besser in die ARMs investiert. Die Spreizung der Leistung ist auch deutlich größer, wenn man sich alleine die ST-Palette anschaut. (Das war für uns letztendlich der Grund, komplett auf STM32 zu gehen: nur noch eine Architektur und eine besonders nach oben hin viel größere Auswahl). Es ist halt die Frage, was er unter "Hobbyprojekt" versteht :-) Schade, dass sich der OP (wie leider so oft) nicht mehr meldet und weitere Angaben macht.
:
Bearbeitet durch Moderator
Debuggen ist ungeheuer wichtig, vor allem beim Einstieg hilft das sehr zu verstehen was im µC passiert. Ein Keil mit einem STM32F030 kann die Werte online darstellen und man sieht während die CPU läuft die Werte und wie die sich ändern und kann sogar neue Werte in Variablen und Register schreiben. Natürlich kann man die CPU auch im Einzelschritt betreiben und sieht welche Befehle er nacheinander abarbeitet und was in den Registern steht. Ob das alles auch beim AVR geht weiß ich nicht, ich habe den AVR zu letzt vor 10 Jahren programmiert und da ging das nicht.
Chris D. schrieb: > Ja, es gibt immer Ausnahmen - aber da ist ein zusätzlicher > Spannungsregler auf dem Steckbrett nicht wirklich ein Problem. Der zieht aber auch dann Strom, wenn der Prozessor schläft. Einziges für mich derzeit wesentliches Argument bei 3,3 V vs. 5 V: will ich die Schaltung mobil aus einer LiIon-Zelle betreiben? Einen 5-V-fähigen Controller kann man da direkt dranklemmen. Der zieht dann ohne große Verrenkungen im Schlaf 1 µA oder weniger. Ansonsten ist das sicherlich egal, und fürs reine Kennenlernen sowieso.
Jörg W. schrieb: > Chris D. schrieb: >> Ja, es gibt immer Ausnahmen - aber da ist ein zusätzlicher >> Spannungsregler auf dem Steckbrett nicht wirklich ein Problem. > > Der zieht aber auch dann Strom, wenn der Prozessor schläft. Das bezog sich auf die LED-Beleuchtung - das macht dann den Kohl wohl nicht mehr fett :-) > Einziges für mich derzeit wesentliches Argument bei 3,3 V vs. 5 V: > will ich die Schaltung mobil aus einer LiIon-Zelle betreiben? Einen > 5-V-fähigen Controller kann man da direkt dranklemmen. Der zieht > dann ohne große Verrenkungen im Schlaf 1 µA oder weniger. Das stimmt, da ist der weite Eingangsspannungsbereich der AVRs von Vorteil. Andererseits hängt es auch da von der Anwendung ab. Ich hab vor Jahren mal ein mobiles Gerät gebaut, da lohnte sich aufgrund des Verbrauchs über den üblichen Nutzungszeitraum (sleep/nosleep-Verhältnis) das Absenken der Spannung trotz des Stroms, den der Regler "verbraten" hat. Insgesamt war die Laufzeit so höher. > Ansonsten ist das sicherlich egal, und fürs reine Kennenlernen sowieso. Ja. Und eine Lösung findet sich im Hobbybereich sowieso für fast jedes Problem - insbesondere, weil man nicht kostenoptimiert arbeiten muss. Müssen wir zwar auch nicht, aber das ist - natürlich - nicht die Regel ;-)
Chris D. schrieb: > Was > kostet ein LM317? 10ct? Iiiiih, LM1117^^ Chris D. schrieb: > Ich sehe da auch bei den ARMs kein großes Problem. Die STM32F0 laufen ab > 2V bis 3,6V. Wenn es sparsam sein soll würde ich aber sowieso mit > Stepdown arbeiten. Da reicht dann tatsächlich ein 3,3V LDO-Regler ... Die gibts ja auch mit Drop-Spannung von 200mV. Wenn der dann die 3,3V nicht mehr regeln kann, hat der Li-Ion-Akku noch ungefähr 5% der Kapazität und je mehr der Li-Ion-Akku entladen wird, desto effizienter wird der LDO ... Anfangs aber mit ca 80% nicht so effizient wie ein StepDown, aber das macht das Kraut nicht fett :) Die STM32 direkt an einen Li-Ion zu hängen könnte problematisch werden, aufgrund der Ladeschlussspannung, die ~4,2V ist.
:
Bearbeitet durch User
m.n. schrieb: >> Naja, es gibt ja auch so was wie den LPC1114/201 im DIP28 und die >> Peripherie ist nicht komplizierter als bei einem AVR. > > Ein schönes, großes Krabbeltier. Ist ja nicht schlecht, aber bei 5 V > Versorgungsspannung zieht es seine Beine ein Laut Datenblatt geht es bis 4.5V also bei 5V Versorgung einfach eine LED davor dann hält er es aus :-)
Mampf F. schrieb: > Die STM32 direkt an einen Li-Ion zu hängen könnte problematisch werden, > aufgrund der Ladeschlussspannung, die ~4,2V ist. Heutzutage verwendet man ja auch Lithium-Eisenphosphat-Akkumulatoren -- sicherer ist das!
Mampf F. schrieb: > Da reicht dann tatsächlich ein 3,3V LDO-Regler Für den musst du aber bei einem batteriebetriebenen Gerät halt noch zusätzliche Kopfstände machen, um ihn auszuschalten, wenn das Gerät ruhen soll. Ist sicher nicht die Anwendung, die man jeden Tag braucht, aber den Controller direkt an eine LiIon-Zelle hängen zu können, finde ich für ein batteriebetriebenes Gerät schon genial. Die ARMs mit 5-V-Fähigkeit gibt es zwar, aber sie sind doch deutlich rarer als die für 3,3 V oder weniger.
/OT Als 3,3V Spannungsregler eignet sich der gut: MCP1702T-3302E - klein - sehr geringer Eigenverbrauch - Kurzschlussfest (250mA) - Übertemperaturfest - bis 12V Vin Ich nehme den gerne. Ich habe meist einen Step-Down Regler auf 5V (LM2674MX-5.0 oder MCP16331T), danach diesen MCP1702 Regler. Durch die 2-Stufige Spannungsreduktion verringert man zudem dass Störungen der Eingangsspannung auf den µC durch kommen und das System läuft stabiler.
:
Bearbeitet durch User
Markus M. schrieb: > Als 3,3V Spannungsregler eignet sich der gut: Quiescent current von 2 µA ist wirklich gut, aber über 600 mV Dropout? Das ist schon eine recht gedehnte Definition von „low drop“, finde ich. Für einen Betrieb mit einer LiIon-Zelle auf jeden Fall viel zu viel. Wir haben aus dem gleichen Hause einen MCP1825 benutzt, der hat nur ganz wenig Spannungsabfall, und bis zu einer Eingangsspannung von unter 2,5 V folgt die Ausgangsspannung dann noch der Eingangsspannung, d. h. er regelt dann zwar nicht mehr, aber bleibt voll durchgesteuert. Allerdings ist der Quiescent Current viel höher, da muss man bei Batteriebetrieb wirklich einen harten Ausschalter vorsehen, oder aber den Regler selbst ausschalten.
Beitrag #4954517 wurde von einem Moderator gelöscht.
Beitrag #4954528 wurde von einem Moderator gelöscht.
Beitrag #4954538 wurde von einem Moderator gelöscht.
Beitrag #4954553 wurde von einem Moderator gelöscht.
Beitrag #4954661 wurde von einem Moderator gelöscht.
Beitrag #4954664 wurde von einem Moderator gelöscht.
Beitrag #4954723 wurde von einem Moderator gelöscht.
Beitrag #4954727 wurde von einem Moderator gelöscht.
Beitrag #4954732 wurde von einem Moderator gelöscht.
Beitrag #4954748 wurde von einem Moderator gelöscht.
m.n. schrieb: > Du hast doch noch nie etwas mit AVRs gemacht. Laß das mal lieber. Ich hab noch ein paar olle AT90 und ATmega32, 128 und 169 hier rumliegen, bin aber nie damit froh geworden. Kannst du haben, zusammen mit 1..2 ebenso alten BlueStreaks. W.S.
Mampf F. schrieb: > Die STM32 direkt an einen Li-Ion zu hängen könnte problematisch werden, > aufgrund der Ladeschlussspannung, die ~4,2V ist. Eben, deswegen sollte man sich auch nicht derart in eine einzige Marke verbeißen, bis - wie hier bereits oft zu lesen ist - das Wort CORTEX M durch ein "STM32" ersetzt ist. Wer mal bei Nuvoton reinschaut, stellt fest, daß die auch recht nette Cortexe bauen - sogar eben auch solche mit eigenem Regler, so daß sie auch an 5 Volt betrieben werden können. Auch bei Freescale gibt's sowas in Form der MKE02..06 Reihen. Die haben allerdings etwas andere Haken... Kurzum, 5 Volt ist auch bei Cortexen kein echtes Gegenargument. Aber der LM317 von Chris war daneben. W.S.
Hol dir einen Arduino Teensy 3.5, oder wenn du etwas weniger ausgeben möchtest, einen 3.2.
Beitrag #4955007 wurde von einem Moderator gelöscht.
Chris D. schrieb: > Schade, dass sich der OP (wie leider so oft) nicht mehr meldet und > weitere Angaben macht. Ist so nicht richtig, ich lese mir alles genau durch und versuche daraus eine Entscheidung abzuleiten :-) Ich denke, dass es später in Richtung Robotik/Modellbau/Displays gehen wird, das ist mein langfristiges Ziel. Es gibt ja auch noch dsPICs, warum sind die weniger beliebt als ARM?
W.S. schrieb: > bin aber nie damit froh geworden. Dann bist du für die Fragestellung allerdings nicht unbedingt der am besten geeignete Ratgeber. Es gibt unzählige Leute, die beides kennen, mit beidem froh geworden sind. Die sind naturgemäß dann weniger voreingenommen als jemand, der eins von beiden nicht mag. Oleg schrieb: > Es gibt ja auch noch dsPICs, warum sind die weniger beliebt als ARM? Zu sehr eigenes Süppchen. Außerdem sind es 16-bit-Controller, das war bei Markteinführung wohl schon kein großer Wurf mehr angesichts der aufkommenden ARM-Welle. Aber selbst bei 32 bit musste Microchip dann unbedingt noch auf MIPS setzen, wenn alle andere rundum ARM machen. Dürfte einer der Gründe gewesen sein, anschließend Atmel aufzukaufen, die schon länger ARM machen und damals gerade erst eine neue ARM-Linie hochgezogen hatten (SAMD & Co.). Selbst die waren schon spät dran – wie du auch an diesem Thread sehen kannst. Bei ARM empfehlen dir die meisten Leute fast automatisch STM32, viel weniger die der anderen Hersteller.
Jörg W. schrieb: > Bei ARM empfehlen dir die > meisten Leute fast automatisch STM32 ... was dann schlicht am Preis liegen dürfte ! Die Discovery- und noch mehr die Nucleo-Boards sind richtig preiswert und liegen auf Arduino-Niveau. Zudem gibt es extremst Billigboards aus China (wie oben mehrfach erwähnt), bestückt mit STM32F103 und STM32F030. Die LPC-Serie ist ja auch nicht schlecht, aber nur deutlich schlechter zu bekommen (für Privatpersonen ist da Watterott mit dem LPC1114 und einem riesigen 28 pol. DIL Gehäuse noch oki!)
Beitrag #4955154 wurde von einem Moderator gelöscht.
Ich arbeite seit einen 3/4 Jahr mit einem LPC17xx und LPC43xx. Aus Erfahrung kann ich daher schrieben, dass die STM32 Reihe von der Peripherie her deutlich besser gelungen ist. Auch das CubeMX von ST nimmt einem deutlich die Arbeit ab und initialisiert den Chip komplett - etwas vergleichbares gibt es von NXP nicht. Wenn NXP da nicht bald nachlegt werden die Marktanteile verliere. Außerdem hat man bei ST die größte Auswahl an Derivaten und Variationen von ARM µC überhaupt und man kann somit preislich das Optimum für das jeweilige Projekt herausholen - ist hauptsächlich in der Industrie von Bedeutung. Daher ist es auch als Hobbyist sehr interessant den STM32 zu verwenden, vor allem dann wenn man für einen späteren Beruf die µC Technik lernen möchte.
:
Bearbeitet durch User
Markus M. schrieb: > Aus Erfahrung kann ich daher schrieben, dass die STM32 Reihe von der > Peripherie her deutlich besser gelungen ist. Ich kannte vorher Atmels SAM3/4 (deren Peripherals ich als ziemlich überfrachtet finde) und SAMD & Co. (deren Peripherals ich gut gelungen finde), da hat mich STM nicht so übermäßig überzeugt. Vor allem wundert mich, dass sie auf einem 32-bit-Prozessor so gut wie nur 16-bit-Peripherals haben (Ausnahme: es gibt Zähler mit 32 Bit). Natürlich hat jeder Hersteller ein paar sehr interessante Dinge mit dabei, bei STM beispielsweise der CCM. Habe ich noch nicht benutzt, aber ich sehe, dass der ein nettes Potenzial hat (OK, dafür muss man natürlich auch den entsprechenden RAM bezahlen). Zu CubeMX kann ich nichts sagen, haben wir nicht benutzt. Wir haben alles „zu Fuß“ gemacht. Viele Abhandlungen im Netz setzen nur auf irgendwelchen Layern oberhalb der Hardware auf, die wirklichen Hardware-Bits werden zuweilen nicht so detailliert erklärt. Das ist aber bei Atmel nicht anders, da bestehen die „Appnotes“ mittlerweile auch oft nur noch aus den Hilfetexten von deren ASF. Das hätten sie sich klemmen können. Die SAM3/4 waren dagegen in Appnotes noch recht gut erklärt.
Jörg W. schrieb: > ...oder ob einem das damit bereits vorgegebene > Abstraktionsniveau genügt, und man sich lieber ans schnelle Lösen von > Problemen macht. Probleme die mit der Abstraktionschicht bei den Arduinos und dessen Framework ja erst enstehen. Das sind dann Probleme, gerade Timing- und Timerprobleme - die bei einer normalen AVR oder auf ARM Programmierung mit "Hausmitteln" garnicht erst auftauchen.
Gibt es denn Einsteigerfreundliche 5V Controller von STM die ihr empfehlen könnt? Andererseits habe ich hier gelesen, dass das mit einem Spannungsregler ganz gut gelöst werden kann. Wenn der 5V Controller also ein Sonderling wäre und eher weniger Einsteigerfreundlich ist, dann ist meine Frage natürlich obsolet. Dieses Bluepill oder Maple Board sieht ganz interessant aus.
Oleg schrieb: > Ich denke, dass es später in Richtung Robotik/Modellbau/Displays gehen > wird, das ist mein langfristiges Ziel. Das ist alles etwas diffus. Sieht man sich in der Arduino-Welt um, scheint es mit AVRs zu gehen. Man kann ja für jede Teilaufgabe einen µC nehmen. > Es gibt ja auch noch dsPICs, warum sind die weniger beliebt als ARM? Es gibt auch schöne Teile von Renesas: RX62, RX63 und RX71M. Die kennt hier allerdings kaum jemand. Egal, was Du machst, als Anfänger solltest Du einfach anfangen. oleg schrieb: > Gibt es denn Einsteigerfreundliche 5V Controller von STM die ihr > empfehlen könnt? STM8 ;-)
m.n. schrieb: > STM8 ;-) Wenn es ratsam ist einfach anzufangen und wenn ich dadurch an den Umgang mit dem ARM herangeführt werde, warum nicht? Ich muss mal nachschauen was der STM8 alles an Board hat, PWM sollte er schon können.
oleg schrieb: > Wenn es ratsam ist einfach anzufangen und wenn ich dadurch an den Umgang > mit dem ARM herangeführt werde, warum nicht? Nein, mit ARM haben die nun überhaupt nichts zu tun (außer dass ein paar Peripherals vom STM32 übernommen worden sind). Wenn du mit einem 8-Bit-Controller als Einstieg anfangen willst, dann bleib' lieber beim AVR: der hat einfach mal die größte Community. Das dürfte für dich entscheidender sein als alles andere.
Jörg W. schrieb: > Nein, mit ARM haben die nun überhaupt nichts zu tun (außer dass ein > paar Peripherals vom STM32 übernommen worden sind) Das stimmt nun mal gar nicht, die STM8 sind 6502 und der ARM wurde aus dem 6502 entwickelt, daher ist Assembler auch sehr ähnlich, teilweise sogar 1:1 wie Arithmetik, Logik und Branches. oleg schrieb: > Ich muss mal nachschauen was der STM8 alles an Board hat STM8 ist vor allem in Automotive stark, aber für private Projekte eher weniger. Hier würde ich EFM8 empfehlen, von Leistung, Tools und Debugger-Preis unschlagbar. AVR ist einfach nur veraltet. Markus M. schrieb: > Ich arbeite seit einen 3/4 Jahr mit einem LPC17xx und LPC43xx. Aus > Erfahrung kann ich daher schrieben, dass die STM32 Reihe von der > Peripherie her deutlich besser gelungen ist Das sind aber grade die ganz alten die noch pinkompatibel zu den ARM7 sein mussten. Bei den Nachfolgern LPC15xx und LPC54xx sieht das ganz anders aus. Allein schon der State-Machine-Timer zur Motorsteuerung, da ist STM32 weit davon weg.
Lothar schrieb: > Das stimmt nun mal gar nicht, die STM8 sind 6502 und der ARM wurde aus > dem 6502 entwickelt Welche Relevanz hat das für heutige Anwendungsfälle? Gerade die Assemblermnemonik interessiert ja nun heutzutage am allerwenigsten.
Lothar schrieb: > Das stimmt nun mal gar nicht, die STM8 sind 6502 und der ARM wurde aus > dem 6502 entwickelt, daher ist Assembler auch sehr ähnlich, teilweise > sogar 1:1 wie Arithmetik, Logik und Branches. Ich habe noch einen 6502 hier zu liegen. Der sieht aber ganz anders aus? Lothar schrieb: > Hier würde ich EFM8 empfehlen Darauf habe ich schon lange gewartet - endlich zeigt sich des Pudels Kern ;-)
Ich habe mir jetzt mittlerweile ein paar Tutorials angeschaut sowohl STM, als auch AVR und PIC, meine Wahl wird wohl für den Einstieg doch auf die 8 Bitter fallen, es ist alles etwas übersichtlicher, sogar die Controller-Headerdateien sind irgendwie verständlicher. Außerdem es gibt z.B. von Microchip Tutorials in C oder das AVR Tutorial scheint auch ausgezeichnet zu sein (sehr ausführliche Erklärungen), also perfekt für Anfänger wie mich. Vielleicht ist für den Anfang wie man so schön sagt "weniger mehr". Bleibt nur noch die Frage welcher 8 Bitter.
Hallo, OK, deine Entscheidung, aber wenn du die Tutorials anschaust, dann werfe noch kurz einen Blick auf die für den LPC1114. Damit hast Du schon einen Fuss in der 32-bit Welt (zb. falls Du einen Debugger kaufst) und die Peripherie ist nicht schwerer als beim AVR. Auf jeden Fall viel Spass :) BG, Tom
Thomas H. schrieb: > aber wenn du die Tutorials anschaust, dann werfe > noch kurz einen Blick auf die für den LPC1114. Danke, irgendwie hab ich LPC ausgeblendet gehabt, klar das schaue ich mir an!
Den billigsten Einstieg in einen mittelgroßen AVR Mikrocontroller erhälst du mit einem chinesischem Arduino Nano clone. Wenn du mit dem klar kommst, wirst du auch mit allen größeren und kleineren AVR's klar kommen.
Stefan U. schrieb: > Den billigsten Einstieg in einen mittelgroßen AVR Mikrocontroller > erhälst du mit einem chinesischem Arduino Nano clone. Warum muß es unbedingt wieder das Billigste sein? Allerorts wird hier argumentiert, daß für Hobby die Hardware-Kosten eine untergeordnete Rolle spielen. Soll er doch bei einem hiesigen Händler einkaufen; heute bestellt, morgen geliefert. Bevor irgendein China-Kram hier ankommt, weiß der TO doch schon längst, wie der Hase läuft und ob ihm die Hardware gefällt. Beispielsweise Arduino Uno R3 mit ATmega328 im DIL-Gehäuse zum einfachen Austauschen: https://www.reichelt.de/Einplatinen-Microcontroller/ARDUINO-UNO-DIP/3/index.html?ACTION=3&LA=446&ARTICLE=154902&GROUPID=6667&artnr=ARDUINO+UNO+DIP&SEARCH=uno
m.n. schrieb: > Warum muß es unbedingt wieder das Billigste sein? Muß es nicht ... man kann für 2€ in China kaufen (mit 2-6 Wochen Lieferzeit), für 5€ in .de (mit Lieferung am nächsten Tag), oder für 20€ (wie von Dir vorgeschlagen, Lieferung am übernächsten Tag). Du hast "Eure Armut widert mich an" nur anders formuliert. Scheint nicht Dein Geld zu sein, das Du da ausgibst. Naja, wird sich schon ändern, wenn Du größer wirst :-)
> Warum muß es unbedingt wieder das Billigste sein?
Selbst wenn es nicht das billigste wäre, ist es dennoch eine Empfehlung
wert.
Jörg W. schrieb: > Dann bist du für die Fragestellung allerdings nicht unbedingt der am > besten geeignete Ratgeber. Jörg, möchtest du denn unbedingt nur Beiträge von Fans lesen? Manchmal verstehe ich dich wirklich nicht. zu STM32: Ralph S. schrieb: > ... was dann schlicht am Preis liegen dürfte Sehe ich nicht so. Vielmehr dürfte die seit vielen Jahren recht aggressive Verteilerei von billigen Discovery-Boards jetzt ihre Früchte tragen. Vor Jahren waren die LPC's im Durchschnitt deutlich billiger als die STM32, obendrein gab es bei den LPC viel früher welche mit einem ordentlichen TFT-Interface und SDRAM-Anschluß. Das hat sich allerdings jetzt einigermaßen relativiert. Ich habe so den Eindruck, daß sich NXP mit dem Ankauf von Freescale bei den µC keinen wirklichen Gefallen getan hat und ST ist in der letzten Zeit konsequent besser geworden. Nur deren immer noch 16 Bit Ports und Timer nerven etwas. Und nach Aussage der NXP-Leute auf der Embedded hat man dort keine Ambitionen, einen M7 herauszubringen. OK, die LPC43xx sind ja auch nicht zu verachten, aber eben erstmal schwierige Kisten mit ihren 2 unteschiedlichen CPU's. Ich selbst hab davon bislang die Finger gelassen, stelle es mir aber ein wenig schwierig vor, in einem Projekt Code sowohl für nen M0 als auch für nen M4F zu vereinen. Vielleicht probiere ich demnächst mal den Onlineshop von Nuvoton aus. Immerhin gehen die M4F dort bei ca. 3.50€ los. Zumindest für mich ist das durchaus ein Argument. Aber mal sehen, wie die Randbedingungen tatsächlich aussehen. W.S.
Markus M. schrieb: > Wenn NXP da nicht bald nachlegt werden die Marktanteile verliere. Die leben bestimmt nicht von den 3 Bastlern die Software nur per Mausklick "schreiben" können und das Handbuch nicht lesen wollen, Die industriellen Anwender werden sicherlich qualifizierte Leute haben die wissen wie man ein Handbuch liest und dann aus dem Handgelenk die 12 Zeilen Code zusammenklöppelt um das Ding zu initialisieren. Codegeneratoren für so einen Pipifax braucht niemand, Dokumentation, ein paar Beispiel-Codeschnipsel für Sachen die sich schwer in Worte fassen lassen und kompetenter Support bei dem keine Fragen offen bleiben sind das Wichtigste.
Der CCM vom Stm32 ist gut. Da kann man den Stack rein machen und alle Variablen die nicht an einem DMA sein müssen. Aber erst den CCM einschalten bevor man den Stack benutzt ;-) Damit hat man mehr Buffer für DMA oder andere Dinge und der Bus/RAM ist frei für den DMA.
:
Bearbeitet durch User
W.S. schrieb: > Jörg, möchtest du denn unbedingt nur Beiträge von Fans lesen? Manchmal > verstehe ich dich wirklich nicht. Nein, aber wenn es um die Frage geht, ob jemand mit einem AVR oder einem ARM einsteigen soll, dann wird jemand, der mit beiden bislang gut zurecht gekommen ist, ein besserer Ratgeber sein als jemand, der von sich selbst sagt, dass er eins von beiden einfach nur gar nicht mag. Derjenige ist naturgemäß voreingenommen. Ich wäre bestimmt der letzte, der irgendwas gegen ARM sagen würde (ich benutze sie seit Jahren beruflich), die Dinger sind gut – aber an Einfachheit bei gleichzeitig immer noch recht zeitgemäßem Design ist ein AVR kaum zu schlagen. Es hat einen Grund, warum sich diese Teile damals überhaupt durchsetzen konnten in einem Markt, der recht gut aufgeteilt zu sein schien.
Markus M. schrieb: > Da kann man den Stack rein machen und alle Variablen die nicht an einem > DMA sein müssen. Oder eben Code, der schnell ausgeführt werden soll. Flash ist schließlich im Durchschnitt immer noch die größte Bremse eines ARM-basierten Controllers.
Also ich war bis kurz vor Jahreswechsel auch ein LPC1xxx-Nutzer. Zum Schluß der LPC15xx. Geiles Teil und gute (Eclipse-basierte) IDE. Insgesamt sind auch die deutlich älteren (LPC11xx) in meine Augen "echte" 32-bitter, während die älteren STM32 sich schon als die erwähnten aufgebohrten 16-bitter geben. Die LPCOpen-Libs sind auch gut, aber das ist ja wie immer Geschmackssache. Die Dev-Boards waren mit ca. 20 € immer etwas teurer, aber Hobby eben. Ausreichende Debugger haben beide an Bord. Zur Hausvernetzungsbastelei waren dann aber leider keine billigen Chinaboards wie das BluePill vorhanden. Also bin ich derzeit für ca. 1,85 € das Stück zu den steinalten STM32F103C8T6 abgewandert. Dafür bekomme ich die nackten LPC-Chips nicht; und schon gar nicht komplett als fix und fertiges Board. Auch so sind die LPC1xxx nicht so dolle zu bekommen. Besser gefallen tun sie mir aber allemale. Ich weiß zwar nicht, ob die BluePills originale Chips drauf haben, aber NXP (oder wer auch immer gerade die Hosen an hat) hätte sicherlich gut daran getan, zumindest einen hobbytauglichen Chip mit dem Chinamann großflächig unters Volk zu bringen.
Der LPC1549 ist ja schon ein relativ fettes Teil, für Haus und Heim reichen auch die LPC8xx, so habe ich jedenfalls Funknodes gebaut. Als günstige Quelle für den LPC824 (32kB Flash, 8kB Ram) hatte ich Conrad gefunden, ja ausgerechnet die blaue Apotheke. Der hatte da in 2016/09 1,70€ (Einzelpreis bei 10 Stück) gekostet, jetzt hat die Inflation zugeschlagen und der Gleiche kostet gerade 2,66€ (2,77€ als Einzeilstück) :-( Trotzdem kann ich den für den Einstieg empfehlen, man darf nur keine Angst vor SMD haben und muss den fürs Breadboard auf eine Adapterplatine packen. Dann braucht man aber nur die 3V anzulegen und der rennt. Zum Programmieren reicht ein USB-RS232 Wandler der auf 3,3V Pegel eingestellt werden kann, kostet keine 3€ bei eBay. Wenn man es bequem haben möchte kann man noch die mbed Lib nehmen und man hat ein C++ API für die Basisperipherie, selbst auf so einem Winzling. Nachtrag wg. sowas wie Cube bei NXP: Ich denke die spüren den Druck den ST macht, mit MCUXpresso hat NXP jetzt auch neue Tools am Start weil NXP ja jetzt auch die aufgekauften Kinetis unterstüzen muss.
Jörg W. schrieb: > Flash ist schließlich im Durchschnitt immer noch die größte Bremse > eines ARM-basierten Controllers Jedes Controllers: auch ein C8051 mit 100 MHz braucht entweder 2 Waitstates oder man muss den Compiler auf ALIGN4 stellen dass alle struct Elemente Adressen bekommen die durch 4 teilbar sind = Speicherverschwendung. Oder man schaltet runter auf 25 MHz ohne Waitstates. Bei den lahmen AVR stellt sich das Problem natürlich erst nicht :-)
Jörg W. schrieb: > Markus M. schrieb: >> Da kann man den Stack rein machen und alle Variablen die nicht an einem >> DMA sein müssen. > > Oder eben Code, der schnell ausgeführt werden soll. Flash ist > schließlich im Durchschnitt immer noch die größte Bremse eines > ARM-basierten Controllers. Ne, Code kann man aus dem CCM RAM nicht ausführen.
Dauergast schrieb >Muß es nicht ... man kann für 2€ in China kaufen (mit 2-6 Wochen >Lieferzeit), für 5€ in .de (mit Lieferung am nächsten Tag), oder für 20€ >(wie von Dir vorgeschlagen, Lieferung am übernächsten Tag). >Du hast "Eure Armut widert mich an" nur anders formuliert. Scheint nicht >Dein Geld zu sein, das Du da ausgibst. Naja, wird sich schon ändern, >wenn Du größer wirst :-) Mir hatte mal jemand von einer Schweizer Uni aus der Mikromechanik erzählt, dass sie ein paar Millionen teures Mikroskop haben, mit dem sie alles direkt sehen können, was die anderen Forschungsgruppen nur erraten können. Mit gutem,passenden, manchmal auch etwas kostenintensiven Material ist man den anderen weit voraus. Tja, und so ist das halt: Wer sich kein vernünftiges Entwicklungssystem leisten kann oder will, muss halt mehr Zeit mitbringen und ist halt langsamer als die anderen. Wobei es schon lächerlich ist, über 20 Euro zu diskutieren. Zwei mal weniger ins Kino und man kann daheim basteln ( Man könnte sogar die Zeit im Kino durch das basteln ersetzen, dann ist es sogar kostenneutral ). Vor 20 Jahren war die Mikrocontrollerentwicklung noch eine ganz andere Liga: Damals musst man zwischen 100 und 1000 DM in die Hand nehmen. Wer heute schnell sein will, kann sich ein fertiges Experimentalsystem kaufen und schnell alles mögliche ausprobieren: https://www.seeedstudio.com/Grove-Starter-Kit-for-Arduino-p-1855.html
@oleg: Nachdem du nun trotz dem ganzen Durcheinander hier schonmal richtig erkannt hast, dass der AVR für einen Einstieg doch besser ist als der ARM, empfehle ich dir immernoch mit dem 13A anzufangen. Du hast ja bereits gesagt, was dein innerlicher Antrieb ist, also machs einfach so. Was stört dich denn so an dem 13A?
:
Wiederhergestellt durch Moderator
Und an die anderen, besonders die, die beruflich mit ARM arbeiten, sei gesagt, dass Einstieg ein stark zielabhängig definierter Begriff ist.
:
Wiederhergestellt durch Moderator
Vielleicht doch noch eine Frage zu ARM, ich konnte sporadisch keine ARM Controller finden, die wirklich Breadboardtauglich sind (von den STM Breakoutboards abgesehen) und auch noch Käuflich sind, den LPC1114FN28 gibt es ja leider nicht mehr weil abgekündigt...Cortex M0/M0+ sieht eigentlich vom Aufbau ganz übersichtlich aus.
@ASM Superprofi > Was stört dich denn so an dem 13A? Mir macht das sorgen: Mampf F. schrieb: > Bei 1k Flash und 64Byte RAM kommt man sehr schnell an dessen Grenze. Der > verwendet den RAM auch als Stack ... Ohje ohje ... Etwas größer sollte > das ganze schon sein, dass man auch sinnvolle Sachen machen kann und > nicht schon zum Code optimieren anfangen muss, bevor man irgendetwas > zustande gebracht hat :) ansonsten spricht der mich wegen des sehr einfachen Aufbaus schon an, auch das Datenblatt mit nichteinmal 200S ist übersichtlich.
Ich möchte mein Anfängerboard für AVR-Controller verkaufen. Dies steht in meinem Shop: http://ups.bplaced.de/Shop/shop.htm ... unter Punkt 4. Man kann auch sehen, was nach dem Anfängerboard entstanden ist.
oleg schrieb: > ansonsten spricht der mich wegen des sehr einfachen Aufbaus schon an, > auch das Datenblatt mit nichteinmal 200S ist übersichtlich. Ich hab bei ein paar meiner letzten Projekten den Tiny84 verwendet ... Der ist auch nicht wesentlich komplexer, hat dafür aber schon 8kB Flash und 512Byte RAM :) Und die SO8-Varianten gefallen mir nicht besonders, weil man mit den Ports schon sehr haushalten muss ... SO14 finde ich von der Größe gut ... Wenn man vUSB verwenden möchte, dann kann man einen Quartz anflantschen (hatte nur Probleme mit vUSB und internem RC-Oszillator trotz Kalibrierung auf die USB-Frames), ohne dass man gleich 2 von 6 Port-Pins verloren hat. Dann noch Reset und noch einer ist weg. 3 braucht man für ISP, dann kann man gleich die Port-Pins wiederverwenden anfangen, bevor man überhaupt irgendwas gemacht hat. Imho sind die SO8-Tinys eher was für Profis als die etwas größeren mit zB SO14 :)
oleg schrieb: > Vielleicht doch noch eine Frage zu ARM, ich konnte sporadisch keine ARM > Controller finden, die wirklich Breadboardtauglich sind (von den STM > Breakoutboards abgesehen) und auch noch Käuflich sind, den LPC1114FN28 > gibt es ja leider nicht mehr weil abgekündigt...Cortex M0/M0+ sieht > eigentlich vom Aufbau ganz übersichtlich aus. Die Abkündigung wird einen Grund gehabt haben: es verarbeitet schlicht niemand mehr DIL-Gehäuse. Am LPC1114 selbst kann es nicht liegen, den gibt es ja in anderen Gehäuseformen weiterhin. Die Frage ist auch, ob man seinen Controller wirklich nach der Gehäuseform aussuchen sollte. Es geht doch in erster Linie um den Leistungsumfang, oder? :-) Ich arbeite auch noch gerne mit Steckbrettern, aber dann entweder mit fertigen Boards (z.B. STM32F0-Discovery, mit Debugger usw. für unter 9€) oder man lötet sich den entsprechenden Chip auf einen Adapter. Hier http://shop.anvilex.de/index.php?route=product/category&path=115_61 gibt es bspw. preiswerte Adapter (auch für's Steckbrett) für fast alle erdenklichen Gehäusetypen. Ab einer gewissen Pinanzahl wird das aber mit Steckbrett und einreihigen Pfostenleisten schwierig. Da muss man dann von der Adapterplatine aus Strippen ziehen.
:
Bearbeitet durch Moderator
Chris D. schrieb: > Die Frage ist auch, ob man seinen Controller wirklich nach der > Gehäuseform aussuchen sollte. Es geht doch in erster Linie um den > Leistungsumfang, oder? :-) Kommt drauf an ... Der Chinese meines vertrauens fertigt Platinen bis 10*10cm supergünstig. Nur 1cm mehr und schon darf man 20$ mehr zahlen ... Also so rum geht aussuchen auch ?
ASM Superprofi schrieb: > Was stört dich denn so an dem 13A? viel zu wenige Beinchen und viel zu wenig RAM. Bei den Beinchen braucht man 2 für die Stromversorgung und, wenn man ISP verwenden will, nochmal eins für Reset. Zum Debuggen ist RS232 praktisch. Braucht nochmal zwei Beinchen. Bleiben 3 Beinchen für andere Zwecke. Das macht keinen Spaß! Unter einem Tiny2313 würde ich nicht anfangen. Die Mega-irgendwas sind aber auch kaum (bei Hobbystückzahlen) teurer. Erleichtert die Lagerhaltung. Ich würde mir einfach mal etwas China-Arduino-Hardware bestellen. Mit einem ISP-Adapter kann man die auch nach eigem Wunsch programmieren. Bis ich Quarz, Kondensatoren und Spannungsregler zusammen habe, bin ich fast beim gleichen Preis. Zur Hardware: ISP-Adapter: braucht man, brauchbares gibts ab 3€ Einen Logic-Analyzer (10€) zum debuggen sollte man sich auch gleich noch zulegen. Schont die Nerven! Ein Oszilloskop (ab 200€) benötigt man am Anfang nicht, aber wenn man es einmal hat, will man es nicht mehr missen. Markus schrieb: >>Du hast "Eure Armut widert mich an" nur anders formuliert. Scheint nicht >>Dein Geld zu sein, das Du da ausgibst. Naja, wird sich schon ändern, >>wenn Du größer wirst :-) > Mit gutem,passenden, manchmal auch etwas kostenintensiven Material ist > man den anderen weit voraus. Nicht nur das, man kommt auch schneller ans Ziel. Auch bei einem Hobbyprojekt werde ich darüber nachdenken, ob ich das in zwei Tagen oder in zwei Wochen umsetzen kann. Dieser Zeitunterschied ist Geld wert. Zwar nicht so viel wie bei einer gewerblichen Entwicklung, aber dennoch einiges.
Chris D. schrieb: > Die Abkündigung wird einen Grund gehabt haben: es verarbeitet schlicht > niemand mehr DIL-Gehäuse. Kann ich nicht bestätigen. Ich sehe immer noch genug (auch viele neue) Geräte mit THT-Bauteilen. Vermutlich auch, weil die entweder sowiso THT-Bauteile (Leistungselektronik...) benötigen, mechanische Vorteile bieten oder auf einem älteren Design basieren. Ein ARM in einem DIL_Gehäuse ist aber einfach exotisch.
Schreiber schrieb: > Kann ich nicht bestätigen. Ich sehe immer noch genug (auch viele neue) > Geräte mit THT-Bauteilen. > Vermutlich auch, weil die entweder sowiso THT-Bauteile > (Leistungselektronik...) benötigen, mechanische Vorteile bieten oder auf > einem älteren Design basieren. Ja, es geht oleg aber um ARM-Mikrocontroller und nicht irgendwelche Leistungselektronik. Und die praktisch nicht existierende Auswahl an DIL-Gehäusen dort stützt meine These. > Ein ARM in einem DIL_Gehäuse ist aber einfach exotisch. Da meine ich. Wäre ein größerer Bedarf vorhanden, gäbe es sie mit ziemlicher Sicherheit. Ich würde mich an seiner Stelle jedenfalls nicht durch die Gehäuseform einschränken lassen. Es ist ja auch nicht so, dass ständig COntroller abrauchen. Während der ganzen Jahre hier waren es wohl keine fünf Stück. Meist lötet man die ICs genau einmal auf die Adapterplatine und das war es dann.
:
Bearbeitet durch Moderator
oleg schrieb: > LPC1114FN28 gibt es ja leider nicht mehr weil abgekündigt LPC810 DIP8 gibt es noch. > Cortex M0/M0+ sieht eigentlich vom Aufbau ganz übersichtlich aus Für den Neu-Einstieg ist Cortex M0/M0+ kein Problem, für den Umstieg von AVR ist zu Cortex M3/M4 zu raten, weil der unaligned Speicherzugriff unterstützt, und in altem AVR Code oft unaligned structs sind, die dann umständlich geändert werden müssen.
oleg schrieb: > Mir macht das sorgen: > > Mampf F. schrieb: >> Bei 1k Flash und 64Byte RAM kommt man sehr schnell an dessen Grenze. Der >> verwendet den RAM auch als Stack ... Ohje ohje ... Etwas größer sollte >> das ganze schon sein, dass man auch sinnvolle Sachen machen kann und >> nicht schon zum Code optimieren anfangen muss, bevor man irgendetwas >> zustande gebracht hat :) Zu Recht. Im Gegensatz zu den ATtiny hat ein ATmega328 in rel. kleinem, steckbarem Gehäuse sämtliche Peripherie, die bei AVR8 zu finden ist. Vollständige Ports, vollständige Timer, Hardware IIC, SPI, USART, ADC, Komparator und genug RAM und Flash-Speicher, um auch ein printf() ohne Einschränkungen benutzen zu können. Man kann alles probieren, ohne zu schnell an Grenzen zu stoßen. Chris D. schrieb: > Ich würde mich an seiner Stelle jedenfalls nicht durch die Gehäuseform > einschränken lassen. Es ist ja auch nicht so, dass ständig COntroller > abrauchen. Während der ganzen Jahre hier waren es wohl keine fünf Stück. Da Du der absolute Anfänger bist, ist das ja eine richtige Erfolgsstory :-(
m.n. schrieb: > Chris D. schrieb: >> Ich würde mich an seiner Stelle jedenfalls nicht durch die Gehäuseform >> einschränken lassen. Es ist ja auch nicht so, dass ständig COntroller >> abrauchen. Während der ganzen Jahre hier waren es wohl keine fünf Stück. > > Da Du der absolute Anfänger bist, ist das ja eine richtige Erfolgsstory > :-( Ja, für achtzehn Jahre Selbstständigkeit und Elektronikentwicklung ist das für uns zwei Anfänger eine gute Quote <:-}
oleg schrieb: > @ASM Superprofi >> Was stört dich denn so an dem 13A? > > Mir macht das sorgen: > > Mampf F. schrieb: >> Bei 1k Flash und 64Byte RAM kommt man sehr schnell an dessen Grenze. Der > ansonsten spricht der mich wegen des sehr einfachen Aufbaus schon an, > auch das Datenblatt mit nichteinmal 200S ist übersichtlich. Ich habe mir mal die Mühe gemacht, dir FAKTEN rauszusuchen: 13A: 176 Seiten. 84A: 286 Seiten. 88: 302 Seiten. mega: 425 Seiten. xmega: 478 Seiten. Menschen haben immer wieder ein grundsätzliches Problem mit rationaler Abwägung von Vor- und Nachteilen. Für deinen Einstieg um eine LED mit einem Taster zum Leuchten zu bringen, nebenbei ein Relais zu schalten und die Temperatur zu messen ist ein 13A völlig ausreichend. Wenn du dein Hobby ausbaust, wirst du sowieso alle Modelle in deiner Schublade haben und je nach Projekt den passenden nehmen. Wenn du allerdings jetzt schon weisst, dass du nur einen µC haben willst, dann nimm den mega. Damit hast du das meiste abgedeckt, musst dann aber damit leben, dass du für eine einfachste Aufgabe einen 32 Pinner nehmen musst, während ich einen tiny10 mit 6 Beinen einsetze ;)
Vielleicht noch ein kleiner Tipp: Man muss Referenzhandbücher zu Mikrocontrollern nicht komplett durchlesen :-) Es gibt dafür die schöne Erfindung des Kapitels. Du brauchst kein USART, kein SPI, kein I2C, usw.? Dann kannst Du diese Kapitel komplett weglassen.
Grössere Modelle haben durchaus Wechselwirkungen. Schonmal den EEPROM eines xmegas programmiert? Das ist ein ALPTRAUM. Bei den tinys ist es wirklich leicht.
> xmega: 478 Seiten.
Wobei man bei den xmega immer zwei Datenblätter benötgt. Eins beschreibt
die Serie, das andere die spezifischen EIgenschafter des Chips innerhalb
der Serie.
Beim Xmega128D3 hat man insgesamt 582 Seiten zu lesen.
Hi, Wollte ich auch gerade schreiben, man erarbeitet sich einen Controller Stück für Stück --> Datenblatt überfliegen und dann nur in die gebrauchten Teile richtig einsteigen. Was man aber mal ansehen sollte ist das Errata. Hatte hier gerade ein Problem, mit korrupter DMA2-Übertragung auf einem STM32F405. Ich wollte schon eine Anfrage auf das Forum loslassen, mich aber noch an das Errata erinnert. Und siehe da, da gibt es einen Bug :(. BTW: Auf der NXP Seite (http://www.nxp.com/products/microcontrollers-and-processors/arm-processors/lpc-cortex-m-mcus/lpc1100-cortex-m0-plus-m0/scalable-entry-level-32-bit-microcontroller-mcu-based-on-arm-cortex-m0-plus-m0-cores:LPC1114FN28) ist der LPC1114 im DIP28 noch "active". BG, Tom
Stefan U. schrieb: >> xmega: 478 Seiten. > > Wobei man bei den xmega immer zwei Datenblätter benötgt. Eins beschreibt > die Serie, das andere die spezifischen EIgenschafter des Chips innerhalb > der Serie. Ah stimmt. Vergessen. Also dann der xmega A4U mit Hardware USB: 339+478=817 Seiten. Wie sieht es da eigentlich bei den ARMs aus?
es kommt ja nicht auf die Quantität sondern auf die Qualität an. Wenn der µC viel Peripherie hat sind auch die DB umfangreicher. Die Qualität fand ich bisher bei Atmel, NXP und ST sehr gut. Und weil bei den komplexen µC das DB alleine teilweise schwierig ist helfen die Hersteller mit Beispielcode, AppNotes und Tools wie Cube (Programmgenerator), Tabellen für Takteinstellungen, Tools für Pinkonfiguration usw. Auch da profitiert der Hobby Anwender einfach von dem Wettbewerb der vielen Anbieter, nur einen tollen µC ohne Support auf den Markt zu werfen reicht heute nicht. Da hängt der Himmel voller Geigen, man muss nur zugreifen.
ASM Superprofi schrieb: > Wie sieht es da eigentlich bei den ARMs aus? Beim STM32F411xC/E hast du 837 Seiten RefMan und 146 Seiten Datenblatt. Das RM finde ich aber recht übersichtlich. Ggf. noch 1731 Seiten Programming Manual. Das habe ich allerdings nur ein einziges Mal wirklich gebraucht für die Hardware-Wurzel.
ASM Superprofi schrieb: > Schonmal den EEPROM > eines xmegas programmiert? Die Xmegas sind eine komplett andere Reihe gegenüber den standard AVRs. Sie haben kein DIP-Gehäuse, keine 1,8-5,5V VCC, kein optionales CAN. Nur der Befehlssatz ist gleich geblieben. Sie haben aber einen recht komplexen Aufbau (Event-System, DMA usw.), da ist kaum noch ein Unterschied zu den ARM. Für den Neuanfang daher nicht zu empfehlen.
ASM Superprofi schrieb: > Menschen haben immer wieder ein grundsätzliches Problem mit rationaler > Abwägung von Vor- und Nachteilen. Wenn man von rationalen Abwägungen spricht, dann ist eh klar, dass es ein ATMega8 werden muss ... - ATMega8 ist sehr populär - Viele Tutorials dafür, man muss Code nur wiederverwenden - Für die 1EUR mehr gegenüber dem Tiny13 hat man sehr viel mehr Resourcen - Die Auswahl an günstigen Dev-Boards mit ATMega8 ist sehr groß Was allerdings kein rationales Argument ist: Die Anzahl der Seiten im Datenblatt. Wie zuvor schon erwähnt - nicht nur von mir - kann man Kapitel über Peripherie, die man nicht benötigt, überspringen. Die XMegas würde ich - aus rationalen Gründen - ebenfalls nicht verwenden. Ist eine seltsame Abart der AVRs ... Welche Lücke sollen die schließen? Die imaginäre zwischen AVR und ARM? Es reicht doch eins von beiden und die XMegas sind unnötig. Sieht man auch an deren Popularität. ASM Superprofi schrieb im Beitrag: > Grössere Modelle haben durchaus Wechselwirkungen. Schonmal den EEPROM > eines xmegas programmiert? Das ist ein ALPTRAUM. Ah, noch einen Grund, keine xmegas zu verwenden ;-) Aber du scheinst ja eine Datenblatt-Phobie zu haben und/oder den Inhalt nicht geistig erfassen zu können^^
:
Bearbeitet durch User
Mampf F. schrieb: > - ATMega8 ist sehr populär Aber nur bei den Leuten, die noch nicht gemerkt haben, daß der ATmega328 der funktionserweiterte ATmega8 ist. ASM Superprofi schrieb: > dass du für eine einfachste Aufgabe einen 32 > Pinner nehmen musst, während ich einen tiny10 mit 6 Beinen einsetze ;) Davon kann man doch bestimmt auch noch Beine abkneifen und in China gekauft kostet der höchtens 10 cent. Bei AVRs bevorzuge ich immer Dies; da bonde ich dann nur soviel Beine dran, wie ich unbedingt brauche.
ASM Superprofi schrieb: > Wenn du dein Hobby ausbaust, wirst du sowieso alle Modelle in deiner > Schublade haben und je nach Projekt den passenden nehmen. Mein. Bei mir gabs früher nur Tiny2313 und Mega32. Heute gibts für fast alles (ausnahme: Bestandsprojekte und Sonderfälle) fast nur noch Mega328. Der Preisunterschied ist einfach zu gering gewrden. > Wenn du allerdings jetzt schon weisst, dass du nur einen µC haben > willst, dann nimm den mega. Damit hast du das meiste abgedeckt, musst > dann aber damit leben, dass du für eine einfachste Aufgabe einen 32 > Pinner nehmen musst, während ich einen tiny10 mit 6 Beinen einsetze ;) Ja und? Wenn die Kanone billig ist, dann kann man auch mit dieser auf Spatzen schießen. Wenn ich bei einem Hobby ein paar Cent sparen kann und mir dafür ein ganzes Bauteilelager anlegen muss, dann werde ich zweimal über die Sinnhaftigkeit des ganzen nachdenken. Beim Auto das gleiche: Ich kauf mir ja auch nicht extra einen Smart, weil ich oft nur mit 1-2 Personen unterwegs bin. Bleiben die Rücksitze halt die meiste (aber nicht die ganze) Zeit leer. Stört ja keinen.
>Beim STM32F411xC/E hast du 837 Seiten RefMan und 146 Seiten Datenblatt. >Das RM finde ich aber recht übersichtlich. Also ich finde ja, er könnte mal mit einem Automotive Mikrocontroller wie dem hier anfangen http://www.nxp.com/products/automotive-products/microcontrollers-and-processors/32-bit-power-architecture/ultra-reliable-mpc56xx-32-bit-automotive-industrial-microcontrollers-mcus/ultra-reliable-mpc567xk-mcu-for-automotive-industrial-radar-applications:MPC567xK und am besten mal die grundlegenden Dokumente dazu durchlesen: Reference Manual : 1773 Seiten Signal Processing Extension: 1110 Seiten Datenblatt Book E: 443 Seiten
Oleg schrieb: > Es gibt ja auch noch dsPICs, warum sind die weniger beliebt als ARM? Die meisten Leute mit einem gesunden Halbwissen, die PIC lesen, denken sofort an die alten 8 Bit Architekturen. Dabei ist PIC24 (dsPIC ist PIC24 + DSP Erweiterungen) eigentlich sehr schön zum Anfangen. Recht orthogonale Prozessorstruktur mit 16 16Bit Registern, deutlich leistungsfähiger als ein AVR (die Teile gibts bis zu 70 MHz und bis zu 512k Flash), gibts auch in DIL, Pincount von 14 bis 144, nur zwei IO-Pins zum Programmieren und Debuggen erforderlich, man kann sich nicht wie bei AVR versehentlich aussperren, gute Peripherie (das macht es eigentlich aus!), billige Debugger verfügbar (PICKIT3-Clones), und der Umstieg auf PIC32 oder PIC12/PIC16/PIC18 ist dann auch nicht mehr so schwer, weil die Peripherie familienübergreifend sehr ähnlich ist. Auf jeden Fall keine Fehlentscheidung. fchk
ASM Superprofi schrieb: > 84A: 286 Seiten > xmega: 478 Seiten EFM8 8-bit 8051: 381+70=451 Seiten LPC810 32-bit ARM: 349+74=423 Seiten Daraus folgt dann wohl ARM ist einfacher :-) Ein Grund warum hier die RM so groß sind ist aber, weil hier vorbildlich als Anhang ein komplettes 8051 bzw. Cortex M0+ Buch dabei ist, mit haufenweise Programmbeispielen, auch in Assembler. Und Source vom Bootloader. Peter D. schrieb: > Die Xmegas sind eine komplett andere Reihe gegenüber den standard AVRs Xmegas wurden auf Legacy gesetzt, schau mal auf die Microchip Homepage
Frank K. schrieb: > Dabei ist PIC24 (dsPIC ist > PIC24 + DSP Erweiterungen) eigentlich sehr schön zum Anfangen. Habe mir mal ein Datenblatt eines PIC24 angeschaut, was mir auf anhieb gut gefallen hat, das Kapitel "Guidelines fo getting started..." da ist sogar eine Minimalbeschaltung gezeichnet. Teilweise auch Beispielcode in C. Das sieht wirklich interessant aus. Ich glaube ich muss mich wohl zwischen PIC24 und ARM M0/M0+ entscheiden.
> "Guidelines fo getting started..." da ist > sogar eine Minimalbeschaltung gezeichnet. Solche Sachen hat Atmel in separate Application Notes gepackt.http://www.atmel.com/products/microcontrollers/avr/default.aspx?tab=documents&Asset_Type=020%20Application%20Note
Moin, Frank K. schrieb: > Auf jeden Fall keine Fehlentscheidung. Aus dem dspic Artikel hier: > Microchip bietet den GCC-basierten Compiler C30 im 3-4 stelligen $-Bereich > an. Eine Studentenlizenz ist kostenlos erhältlich. Nach der Erprobungszeit > ist lediglich die Art der Optimierung nicht mehr frei wählbar. Danke, aber nein danke. Ich setze heute sicher keinen Prozessor ein, der nicht von der Standard GNU Toolchain oder von mir aus noch LVMM kostenfrei supportet wird. Nein, ich werd' mich deshalb auch nicht als Student ausgeben. Sollen ihre crippleware mitsamt ihren Chips behalten. Gruss WK
:
Bearbeitet durch User
oleg schrieb: > Frank K. schrieb: >> Dabei ist PIC24 (dsPIC ist >> PIC24 + DSP Erweiterungen) eigentlich sehr schön zum Anfangen. > > Habe mir mal ein Datenblatt eines PIC24 angeschaut, was mir auf anhieb > gut gefallen hat ... Ich glaube ich muss mich wohl > zwischen PIC24 und ARM M0/M0+ entscheiden. Auch wenn die PIC24 Architektur durchaus schnuckelig ist, bedenke auch, daß das trotzdem eine proprietäre Architektur ist. Die gibt es nur von Microchip. Was heißt, daß du auch für die Toolchain auf Microchip angewiesen bist. Wenn MCP einen optimierenden Compiler nur gegen Geld abgibt oder dich für das Debuggen auf ein bestimmtes Host-Betriebssystem zwingt, dann mußt du dem folgen. Für Cortex/M hingegen hast du die breite Auswahl an Herstellern nicht nur für die Hardware, sondern auch für die Toolchain.
Axel S. schrieb: > Auch wenn die PIC24 Architektur durchaus schnuckelig ist, bedenke auch, > daß das trotzdem eine proprietäre Architektur ist. Die gibt es nur von > Microchip. Das ist bei xAVR (xMega, jetzt Legacy, siehe Microchip-Website), AVR32 (wohl bald auch Legacy) und AVR (?) nicht anders. Oder TI MPS430, auch eine nette Architektur. Oder die ganzen Renesas-Geschichten. Microchip muss man zugute halten, dass sie noch nie Chips wirklich hart abgekündigt haben - die alten Kamellen sind eben nur immer teuer geworden, um den Industriekunden (und nur die spielen eine Rolle, Bastler sind unwichtig) zum Umstieg auf modernere Varianten zu bewegen. Ihre Compilergeschichten sind zwar ärgerlich, aber für den Bastler eher nicht praxisrelevant. Das zielt eher darauf ab, Industriekunden zu melken, die mit einer höheren Optimierungsstufe statt einem 8k-Chip einen 4k-Chip nehmen können und damit in 100000'er Auflagen noch 8 Cent an Stückkosten sparen. Der pragmatische Bastler nimmt einfach den Chip mit dem meisten Speicher aus der Serie, und gut ists. Der Opensource- und Linux-Aktivist wird da zwar schreien, aber die Schreie verhallen im Echten Leben™. Immerhin haben sie eine durchaus brauchbare Lösung für Windows, OSX und Linux hinbekommen. Wenn ich mir das Atmel-Debakel mit Atmel Studio 5 und höher anschaue, dann ist mir MPLABX echt lieber. Und wenn ich mir das Debugging unter Linux mit Avrice anschaue, dann möchte ich damit nicht mein Geld in einem zeitkritischen Projekt verdienen müssen. In der Industrie ist es kein Problem, ein paar Kiloeuro für den 8051-Keil Compiler oder IAR EW8051 hinzulegen. So ist halt das Leben abseits des "safe space" hier. fchk (gerade einen extrem proprietären 8051-RF-SOC bearbeitend)
oleg schrieb: > ich konnte sporadisch keine ARM > Controller finden, die wirklich Breadboardtauglich sind https://www.pjrc.com/store/teensy32.html Da ist alles drauf, was Du brauchst. Und (wahrscheinlich) noch ein bißchen mehr.
Kann mir mal einer sagen, wo auf der Microchip Seite die xmegas jetzt NRND sein sollen? Ich kann da nichts finden. Ausser die alten Ax, aber die wurden ja vor Jahren durch die AxU ersetzt.
Lothar schrieb: > für den Umstieg von > AVR ist zu Cortex M3/M4 zu raten, weil der unaligned Speicherzugriff > unterstützt, und in altem AVR Code oft unaligned structs sind, die dann > umständlich geändert werden müssen. Hä? Der Compiler wird einfach Padding einfügen wenn die structs schlampig aufgebaut sind sind. Das tut er mit altem Code genauso gut wie mit welchem der von frischen Anfängern geschrieben wurde, oder glaubst Du heutige Anfänger kümmern sich sorgfältiger um ihre structs als alte AVR-Nutzer? Wahrscheinlich kümmert sich keiner davon auch nur die Bohne darum und der Compiler erzeugt dennoch lauffähigen Code.
Frank K. schrieb: > ein paar Kiloeuro für den 8051-Keil Compiler Der ist doch mittlerweile umsonst von den meisten Herstellern zu bekommen z.B. für EFM8 > gerade einen extrem proprietären 8051-RF-SOC bearbeitend TI?? Ich dachte dafür wäre IAR EW8051 umsonst Bernd K. schrieb: > Der Compiler wird einfach Padding einfügen wenn die structs schlampig > aufgebaut sind sind Wie soll das denn gehen? Wenn eine struct z.B. char/char/short hat und es wird direkt mit einem Pointer auf den zweiten char zugegriffen gibt es auf Cortex M0 einen Hardfault. Der hat ja zudem auch keinen Memoryfault Handler wo man noch was tun könnte. Erst bei Cortex M3 kann der Compiler was machen: https://www.iar.com/support/tech-notes/general/unexpected-usagefault-or-hardfault-exceptions/ Hier hat mal einer versucht den ENC28J60 Ethernet Stack von AVR auf Cortex M0 zu portieren, aussichtslos.
Nachdem ich einige Erfahrung mit AVR Mikrocontrollern hinter mir habe, probiere ich gerade einen STM32F103rB aus - in Form eines Nucleo-64 Boardes. Für geübte Programmierer mag der Chip und die Software kein Problem sein. Aber ich tu mich gerade beim ersten Programm (LED Blinker) verdammt schwer. Ich habe hunderte Seiten Doku gelesen und probiere seit 10 Stunden diverse Treiber und Programme aus. Letzendlich bin ich beim SW4STM32 geladet, obwohl ich eigentlich Netbeans verwenden wollte. Darauf komme ich vielleicht später nochmal zurück. Jedenfalls blinkt meine LED immer noch nicht. Das kann ich Einsteigern wirklich nicht empfehlen. Bis zum ersten Erfolgserlebnis kommt mir der Weg viel zu lang vor. Wenn ich nicht schon lange mit Eclipse und GCC vertraut wäre, hätte ich es noch schwerer. Nur so nebenbei: Mein erster AVR (ATtiny13) blinkte schon am ersten Abend.
> Jedenfalls blinkt meine LED immer noch nicht.
Juhu, sie blinkt. Stolz bin ich allerdings nicht drauf, denn das
Programm ist 4152 Bytes groß. Dieses Zusammenklicken mit CubeMX ist wohl
nicht der Hit.
Lothar schrieb: > Wie soll das denn gehen? Wenn eine struct z.B. char/char/short hat und > es wird direkt mit einem Pointer auf den zweiten char zugegriffen gibt > es auf Cortex M0 einen Hardfault. Nein. Char erfordert 1-align, short erfordert 2-align, das struct wird also wie folgt repräsentiert:
1 | Offset |
2 | 0 erstes char |
3 | 1 zweites char |
4 | 2 short (lo) |
5 | 3 (hi) |
Es ist kein Padding erforderlich alle 3 können direkt gelesen werden. Und selbst wenn man die Reihenfolge ungünstig vertauscht, also z.B. char/short/char dann fügt der Compiler einfach padding ein und es lässt sich trotzdem benutzen als wenn nichts wäre:
1 | Offset |
2 | 0 erstes char |
3 | 1 - (padding) |
4 | 2 short (lo) |
5 | 3 (hi) |
6 | 4 zweites char |
7 | 5 - (padding) |
(In diesem Falle wird das ganze Struct am Ende nochmal mit einem weiteren Byte auf vergrössert weil sein Member mit dem striktesten Alignment 2-align braucht, somit also das ganze struct als ganzes ebenfalls 2-align braucht)
:
Bearbeitet durch User
>Jedenfalls blinkt meine LED immer noch nicht. Das kann ich Einsteigern >wirklich nicht empfehlen. Bis zum ersten Erfolgserlebnis kommt mir der >Weg viel zu lang vor. Ach komm, das Referenz-Manual des STM32F103 hat gerade mal 1173 Seiten: http://www.st.com/content/ccc/resource/technical/document/reference_manual/59/b9/ba/7f/11/af/43/d5/CD00171190.pdf/files/CD00171190.pdf/jcr:content/translations/en.CD00171190.pdf Manche sagen, die Bibel hätte imerhin 1550 Seiten ...
Die Bibel habe ich schon gelesen, auch den Koran. ABer das hilft mir hierbei leider nicht :-)
>Die Bibel habe ich schon gelesen, auch den Koran.
Alle Achtung, das zeigt, dass Du Ausdauer hast. Das sind schon mal gute
Voraussetzungen für's Manual lesen :-)
Also bei mir ging der Einstieg in die Cortex M3 Welt recht flott und erfolgreich. Bin ehrlich gesagt begeistert von den Möglichkeiten. CubeMX habe ich nicht benutzt. Liegt das ev. an unterschiedlichen Herangehensweisen?
PS: Es spielt doch gar keine Rolle wieviele Seiten das Reference Manual hat. Man benötigt doch immer nur einen kleinen Teil zur gleichen Zeit. Wegen mir könnte es auch 3000 Seiten haben. Wäre völlig unerheblich. Davon darf man sich nicht beängstigen lassen :)
Stefan U. schrieb: > Die Bibel habe ich schon gelesen, auch den Koran. ABer das hilft mir > hierbei leider nicht :-) Das Manual hat meistens ein gegliedertes Inhaltsverzeichnis, ist sinnvoll und logisch strukturiert, widerspricht sich nicht selbst und enthält auch keine haarsträubenden Anekdoten aus vergangenen Zeiten die nichts zum eigentlichen Thema beitragen.
wutz schrieb: > Wegen mir könnte es auch 3000 Seiten haben. Wäre völlig unerheblich. > Davon darf man sich nicht beängstigen lassen :) Das ganze www hat mehr als 1 Milliarde "Kapitel" mit jeweils geschätzt mehrstelliger Seitenzahl, Es hat kein strukturiertes Inhaltsverzeichnis, Qualität und Wahrheitsgehalt schwanken stark. Trotzdem kann man darin lesen (sogar zielgerichtet und wissensgewinnend) und kaum einer hat Angst vor dessen Größe.
:
Bearbeitet durch User
Stefan U. schrieb: > Juhu, sie blinkt. Stolz bin ich allerdings nicht drauf, denn das > Programm ist 4152 Bytes groß Wie gesagt bei einem LPC wäre das ganz einfach gewesen und die Programme sind Dank Codebase auch sehr klein. Schließlich hat ein LPC810 nur 4K Flash :-) https://github.com/microbuilder/LPC810_CodeBase Lothar schrieb: >> Einstieg mit einem kleinen ARM im DIP-Package auf Steckbrett > > DIR0_bit.P0_0 = 1; > PIN0_bit.P0_0 = 1;
Stefan U. schrieb: > Juhu, sie blinkt. Stolz bin ich allerdings nicht drauf, denn das > Programm ist 4152 Bytes groß. Erst Spannungsregler, jetzt blinkende LEDs. Bei einem AVR wird das Programm vielleicht 50 Bytes brauchen. Daraus folgert, nein, das ist der Beweis, daß die Programmlänge von der Seitenanzahl des Datenblattes abhängt ;-)
m.n. schrieb: > Daraus folgert, nein, das ist der Beweis, … dass du einfach nur sinnlose Polemik lieferst. Die Größe eines Trivialprogramms hat doch nun absolut nichts damit zu tun, was in der realen Welt da so rauskommt. Das hatten wir schon mal mit Moby durch, der am Ende klein beigeben musste, als Yalu ihm demonstriert hat, dass sein „hochoptimierter“ (sprich teurer, weil mit vielen Stunden Arbeitszeit erstandener) Assemblercode doch noch von einem C-Programm zu schlagen war. Den Code für die kleinste blinkende LED bekommt man, wenn man es unbedingt haben will, auch bei einem ARM noch komplett in der Vektortabelle unter. Einzig die Einträge für die Initialisierung des Stacks und der Reset-Vektor sind Pflicht, alles andere kann man auch dort schon mit Code belegen. Wirklich Sinn hat das bloß nicht.
Jörg W. schrieb: > m.n. schrieb: >> Daraus folgert, nein, das ist der Beweis, > > … dass du einfach nur sinnlose Polemik lieferst. Ich sehe, Du bist ironieresistent. Aber das ist Dein Problem. Ich denke, andererseits ist die Bedeutung von ";-)" bestens bekannt. Völlig abwegig ist es hingegen, den Namen "Moby" ins Gespräch zu bringen. Wenn Du meine obigen Beiträge gelesen hast, wüßtest Du, daß ich weder ARM noch AVR ausschließe. Oder sind die jetzt alle gelöscht? Wenn hier Stefan U. die Codegröße eines nichtssagenden Programmes als mögliches Argument gegen ARM aufführt, hilft das dem TO doch in keiner Weise. Da frage ich mich doch: was hat das hier zu suchen? Genausowenig hilft die Diskussion über die Seitenanzahl von Datenblättern oder die Verwendungsmöglichkeiten vom LM317-Reglern. Aber gut. Derzeit segelt der TO auf PIC24-Kurs. Meinetwegen. Wichtig ist nur, daß er einfach mal mit irgendeinem Teil anfängt, als weiter den Stein des Weisen zu suchen.
Ohne jetzt alles durchgelesen zu haben, ich programmiere seit vielen Jahren 8Bit AVRs - Ich hab mal in ein STM32 geschnuppert und muss feststellen: "Puh, das ist ne ganz andere Hausnummer!" Mit diesen ganzen Registerzeugs fühlt man sich am Anfang erstmal erschlagen - nicht von einem Ast, sondern von einem ganzen Wald! Und die grundlegendsten Funktionsweisen eines µC - hätte ich sicher schon beim ersten "Blinky" die Segel geschstrichen. Wenn man diese Register erstmal in der Grundsubstanz überschaut hat, mag es dann langsam gehen. Aber für den Anfang im µC Bereich ist das der absolute Overkill.
m.n. schrieb: > Ich sehe, Du bist ironieresistent. Full ACK. Und das obwohl Freitag und bestes Wetter ist und man eigentlich tief entspannt in den Tag gehen sollte. Das Tolle bei den Cortex-M ist doch nicht das man damit das kleinstmögliche Programm schreiben kann (was würden die PIC10 User dazu sagen?), sondern die Bandbreite an µCs die man damit einsetzen kann: von den kleinen M0 im TSSOP20 Gehäuse das nicht grösser ist als ein Tiny und trotzdem zB 32kB Flash und 8 kB Ram haben bis zu den Boliden mit 2MB Flash und 512kB Ram und Ethernet und Displaycontroller (STM32F4/7). Und das alles zu Programmieren mit Werkzeugen und Libs für lau und bei einigen µC die man sogar zu Schüttgutpreisen bekommt. Ich finde dafür lohnt es sich es was Zeit zu investieren sich da reinzuarbeiten.
Ich hatte 1993 mit dem AT89C2051 angefangen. Das war einer der ersten Flash-MCs aber noch nicht ISP programmierbar. Er wurde sehr populär und auch viel von Bastlern verwendet. Er wird wohl auch industriell viel eingesetzt. Wir setzen ihn auch ein und er ist einer der wenigen ICs, die keine Lieferprobleme haben und nicht abgekündigt sind. Es gibt ihn auch als AT89LP4052 ISP programmierbar und schneller. Der MSC-51 Befehlssatz ist auch sehr schön geeignet für Assemblerprogrammierer.
Frank K. schrieb: > Axel S. schrieb: > >> Auch wenn die PIC24 Architektur durchaus schnuckelig ist, bedenke auch, >> daß das trotzdem eine proprietäre Architektur ist. Die gibt es nur von >> Microchip. > > Das ist bei xAVR (xMega, jetzt Legacy, siehe Microchip-Website), AVR32 > (wohl bald auch Legacy) und AVR (?) nicht anders. Das ja. Aber die Toolchain ist Open Source. Und konkret beim avr-gcc gab es Verbesserungen am Compiler, die nicht vom Hersteller kamen. Mit einem closed Source Compiler wäre das nicht passiert. > Microchip muss man zugute halten, dass sie noch nie Chips wirklich hart > abgekündigt haben Das ist mir als Bastler egal. > Ihre Compilergeschichten sind zwar ärgerlich, aber für den Bastler eher > nicht praxisrelevant. Ganz im Gegenteil. Es trifft nur den Bastler. Ein Industriekunde hat kein Problem, auch mal ein paar 1000$ für den Compiler hinzulegen. Der legt das halt später auf seine Kunden um. Der Bastler hat im Zweifel gar kein Budget. > Der Opensource- > und Linux-Aktivist wird da zwar schreien, aber die Schreie verhallen im > Echten Leben™. Tja. Ich schreie gar nicht. Ich kaufe das Zeug einfach nicht. Und falls mal jemand fragt warum, dann sage ich ihm das gerne. Mag sein, daß das auf Kopfschütteln stößt, wie bei dir gerade eben. Aber wenn ich mich so umsehe, dann hat bei vielen Herstellern mittlerweile ein Umdenken Richtung Open Source eingesetzt. Sogar Microsoft "Open Source is Communism!!1!elf" ist auf diesen Zug nicht nur aufgesprungen, sondern möchte sogar Lokomotivführer sein.
Mangels Antwort frage ich nochmals: WO steht bitte was davon, dass die xmegas NRND sind? Wiedermal Fake News? Gleich mal das Wahrheitsministerium anrufen...
m.n. schrieb: > Ich sehe, Du bist ironieresistent. Sorry, war wohl noch nicht recht ausgeschlafen. Den Smiley hatte ich sowieso völlig übersehen, und leider gibt's ja genügend Zeitgenossen in diesem Thread, die solcherart Statements wie deins völlig ernst meinen.
Beitrag #4957855 wurde vom Autor gelöscht.
> Wenn hier Stefan U. die Codegröße eines nichtssagenden Programmes als > mögliches Argument gegen ARM aufführt, hilft das dem TO doch in keiner > Weise. Das stimmt nicht. Ich habe die Codegröße nicht als Gegenargument verwendet, sondern lediglich darauf hingewiesen, dass ich mit meinem zusammengeklickten programm nicht zufrieden bin. Damit habe ich nicht ARM abgewertet, sondern meine eigene Arbeit. Mein programm ist Käse.
ASM Superprofi schrieb: > Wiedermal Fake News? Gleich mal das Wahrheitsministerium anrufen... Hmm, also ich hab AVR32, ATSAM3 und AT91SAM7 unter Legacy-Products gefunden. Die XMegas scheinen tatsächlich nicht dazu zu gehören :)
Ausgenommen die veralteten und verbuggten Ax Modelle, die durch die AxU abgelöst wurden.
Draconix schrieb: > Mit diesen ganzen > Registerzeugs fühlt man sich am Anfang erstmal erschlagen - nicht von > einem Ast, sondern von einem ganzen Wald! Wenn ich ein gutes und verständliches Tutorial finde, welches mir das mit den Registern, dem Startupcode und Makefile klar und deutlich erklärt wäre mir das egal, ich würde die Zeit investieren. Vermutlich ist es eh am besten die Register direkt anzusprechen, denn dann kann man ja direkt mit dem Datenblatt arbeiten. Parallel würde ich sowieso mit einem 8 Bitter was machen damit es nicht so langweilig wird :-)
Peter D. schrieb: > Es gibt ihn auch als AT89LP4052 ISP programmierbar und schneller 8051 ist top :-) aber schau dir mal im Vergleich die neuesten EFM8 an - Leistung, Peripherie, Preis Mampf F. schrieb: > AVR32, ATSAM3 und AT91SAM7 unter Legacy-Products Hab AVR32 mit xmega verwechselt. Gab parallel eine andere Diskussion was aus Arduino Due wird falls ATSAM3 tatsächlich abgekündigt wird. Hiess ja immer Microchip macht sowas nicht, aber warum dann auf Legacy setzen ... Bernd K. schrieb: > dann fügt der Compiler einfach padding ein Dann gib mal hier in der Forum Suche "stm32 hardfault" ein und hilf all den Leuten ...
Axel S. schrieb: >> Microchip muss man zugute halten, dass sie noch nie Chips wirklich hart >> abgekündigt haben > > Das ist mir als Bastler egal. Eigentlich nicht. Wenn sich etwas bewährt hat, dann wird die Entwicklung ökonomisch sinnvoll verwertet. Entweder als Bausatz, Lizens oder als Fertiggerät. >> Ihre Compilergeschichten sind zwar ärgerlich, aber für den Bastler eher >> nicht praxisrelevant. > > Ganz im Gegenteil. Es trifft nur den Bastler. Ein Industriekunde hat > kein Problem, auch mal ein paar 1000$ für den Compiler hinzulegen. Der > legt das halt später auf seine Kunden um. Der Bastler hat im Zweifel gar > kein Budget. So ist es. Ich habe übrigens mit Bascom angefangen. Erst mit der eingeschränkten kostenlos-Version später mit der (auch für Hobbybastler) bezahlbaren Vollversion weitergemacht. Heute kommen aus Zeitgründen allerdings meist die Arduino-Derivate zum Einsatz. Da geht die Entwicklung noch schneller... Bei Industriekunden ist der Preis für die Software weitestgehend egal. Wenn die Lizensen pro Arbeitsplatz und Jahr 3000€ kosten, dann erhöht das den Stundensatz um 2€. Als Hobbybastler sind 3000€ das Gesamtbudget für die nächsten 10 Jahre.
Stefan U. schrieb: > Ich habe hunderte Seiten Doku gelesen und probiere seit > 10 Stunden diverse Treiber und Programme aus. GRRMPFF... Du sollst nicht 10 Stunden lang "diverse Treiber" ausprobieren, sondern innerhalb dieser Zeit begreifen, wie der Hase läuft und dann selbst was zustande bringen. Es ist doch so UNSÄGLICH EINFACH! Also: Den Pins ihre erwünschte Funktion zuweisen, den Takt aufsetzen, dann main aufrufen und schon kann es los gehen. Fertig.. für's erste. Lade dir mal das herunter: "https://www.mikrocontroller.net/attachment/316790/STM32F103C8T6.ZIP"; und lies es dir durch. Das ist ein Minimal-System, was auf nem chinesischen ST-Link2 für stolze 2 Euro oder so läuft und du kannst per USB CDC damit kommunizieren. Das sollte doch zum Kuckuck nochmal ein begehbarer Einstieg sein. Oder ist das auch schon zu kompliziert? Chris D. schrieb: > Es gibt dafür die schöne Erfindung des Kapitels. Das war zwar ein netter Spruch, aber ich würde dich dafür dazu verdammen, einmal einen Kinetis MKE06xxx aufzusetzen, OHNE deren Kinetis-Blabla-Studio verwenden zu dürfen. Kapitel sind schön, wenn dort alles drinsteht, was tatsächlich zum Kapitel gehört. Noch einer mit Tutorial-Bedürfnuis: oleg schrieb: > Vielleicht doch noch eine Frage zu ARM, ich konnte sporadisch keine ARM > Controller finden, die wirklich Breadboardtauglich sind (von den STM > Breakoutboards abgesehen) und auch noch Käuflich sind oleg schrieb: > Wenn ich ein gutes und verständliches Tutorial finde, welches mir das > mit den Registern, dem Startupcode und Makefile klar und deutlich > erklärt wäre mir das egal, ich würde die Zeit investieren. Also dann schau dir den obengenannten Link an. Da findest du beides: einen ARM-Cortex M3 und sogar dank Platine (Eagle) ziemlich Steckbrett-tauglich. Sowie ein Minimalsystem auf selbigem, worauf man aufbauen kann. Keil und Eagle wirst du ja noch herunterladen können. Aber beeile dich mit Eagle! W.S.
Es gab schon viele Antworten, da gebe ich auch meinen Senf dazu: Man versuche möglichst NICHT, das Programmieren UND den Umgang mit einem Mikrokontroller GLEICHZEITIG zu lernen! Als Anfänger verursacht das meist nur Frust, oder es bleibt für ewig dabei, dass man "Programmbruchstücke" irgendwie zusammen kopiert, ohne wirklich zu verstehen, was intern vorgeht. Versucht man beides, stösst man gleich am Anfang auf Befehle wie: cli(); IO_Register->Blabla &= ~(x& 00001b); sei(); .... Dann hat man die Doppelaufgabe den Code zu verstehen UND den Prozessor. Kann man noch gar nicht programmieren, würde ich erst mal einen der 1000 Einsteigerkurse in Foren, auf Youtube oder in einem klassischen Buch empfehlen. VisualC++ downloaden und an einem PC lernen. Der stürzt auch nicht ab, und die Clock ist schon auf 4Ghz gesetzt. ;-) Danach einen Uno kaufen und spielen. Hat man dann nach 2 Monaten noch Lust weiter zu machen, stehen genug Wege offen. Als Sprache würde ich in jedem Falle C empfehlen.
W.S. schrieb: > Du sollst nicht 10 Stunden lang "diverse Treiber" ausprobieren, sondern > innerhalb dieser Zeit begreifen, wie der Hase läuft und dann selbst > was zustande bringen. > > Es ist doch so UNSÄGLICH EINFACH! Ich hab das genauso mit USB CDC auf dem STM32F103 gemacht xD Das war ein Sonntag - ziemlich genau 10h - und nach dem uhm ähm 9ten Versuch oder so hat's dann endlich geklappt ;-) W.S. schrieb: > Lade dir mal das herunter: > "https://www.mikrocontroller.net/attachment/316790/STM32F103C8T6.ZIP"; > und lies es dir durch. Das ist ein Minimal-System, was auf nem > chinesischen ST-Link2 für stolze 2 Euro oder so läuft und du kannst per > USB CDC damit kommunizieren. Ja wahnsinn! Hab mir wirklich die Finger wund gegoogelt und etliche USB CDC Codes getestet, bis ich zähneknirschend aufgegeben hab und mich schlussendlich meinem Schicksal - an ST's HAL und CubeMX gebunden zu sein - hingab und meinen bereits HAL-freien und funktionierenden Code nach HAL portieren musste :S Den werde ich auch noch testen ... :)
:
Bearbeitet durch User
oooooooder man machts mit Assembler. Da gibts keine Konstrukte ;) Für die meisten kleinen Basteleien (wo der Code kaum länger als ein paar Seiten wird) ist doch Assembler völlig ausreichend. Meistens gehts doch darum, Pins einzulesen und je nach Status andere Pins zu schalten. Meistens sind es doch so Sachen wie: temperatur > X? wenn nicht, springe zu ende ausgang4 schalten led3 schalten ende: Und nichtmal mehr SPI muss man heutzutage noch selber programmieren. Einfach nur "sts SPDR,r16" und schon geht das Byte in r16 auf Reisen. Ob man jetzt "sts SPDR,r16" schreibt oder "SPDR = 123" ist doch nun wirklich kein grosser Unterschied. Allerdings besteht für einen Einsteiger in C die Gefahr, auf die Idee zu kommen, sowas wie "SPDR = 'Hallo Welt'" schreiben zu wollen.
Einverstanden. Bei ASM muss man vorher noch ldi r16,123 schreiben. Nicht hauen! ;)
ASM Superprofi schrieb: > Für die meisten kleinen Basteleien (wo der Code kaum länger als ein paar > Seiten wird) ist doch Assembler völlig ausreichend. Du scheinst einen Hang zum Minimalismus zu haben ... Finde ich prinzipiell nicht schlecht, allerdings ist das mittlerweile unnötig. Evtl resultiert das auch aus deiner Liebe zu den 8-pinnigen Tinys ... Evtl ist da der C-Compiler schon damit überfordert xD Was mich halt ein bisserl stört ... Bei dir schwingt immer so ein "Ich bin so geil" mit ... Ich bin so geil, mir reichen 8Pins ... Ich bin so geil, mir reicht Assembler usw^^
:
Bearbeitet durch User
Es findet sich sicher jemand, der auf dem AtTiny einen Cross-C-Compiler für einen Intel-PC schreibt und damit die neueste PC-Software schreibt... ;-)
ASM Superprofi schrieb: > Für die meisten kleinen Basteleien (wo der Code kaum länger als ein paar > Seiten wird) ist doch Assembler völlig ausreichend. Meistens gehts doch > darum, Pins einzulesen und je nach Status andere Pins zu schalten. Stimmt schon, nur will man normalerweise auch noch ein Display dranhängen, zwei Taster und ein kleines Menü für irgendwelche Einstellungen dazubasteln. Das wird mit Assembler schnell extrem lästig, selbst dann, wenn es sich nur um eine 7-Segment-Anzeige handelt. Ich bleibe dabei: mit Basic oder C (einschließlich dessen Derivate) kommt man in der halben Zei4t ans Ziel. Eine LED kann man mit 6 Zeilen Basic ohne nachdenken zu müssen zum Blinken bringen. Schneller geht es nicht!
Mampf F. schrieb: > Was mich halt ein bisserl stört ... Bei dir schwingt immer so ein "Ich > bin so geil" mit ... Ich bin so geil, mir reichen 8Pins ... Ich bin so > geil, mir reicht Assembler usw^^ Dann sieh es halt anders: Ich bin so arm, dass ich mir nichtmal leisten kann, einen mega für eine einfache LED-Blinkerei zu nehmen!!! Ich bin so dumm, dass ich C nicht kapiert habe und deshalb bei ASM Zuflucht gesucht habe.
Schreiber schrieb: > Stimmt schon, nur will man normalerweise auch noch ein Display > dranhängen, zwei Taster und ein kleines Menü für irgendwelche > Einstellungen dazubasteln. Ab "Display dran mit Menüführung" bin ich durchaus damit einverstanden, die Sache in C anzugehen... ... obwohl ich meine TFTs mit ASM ansteuere. Hach ich bin ja so geil!! Für Mampfi: Da ich zu blöd bin zu kapieren, wie man ASM mit C Objekten mischt, musste ich tatsächlich eine TFT Lib in ASM schreiben :(((((( ;)
ASM Superprofi schrieb: > ldi r16,123 ARM Assembler ist besser, einfacher, orthogonaler, und sowieso :-) W.S. schrieb: > Kinetis-Blabla-Studio Da gibt es doch jetzt das ganz neue und tolle MCUXpresso :-) Bereite mich grade auf den Zwangsumstieg von LPCXpresso vor ... http://www.nxp.com/products/software-and-tools/run-time-software/mcuxpresso-software-and-tools/mcuxpresso-integrated-development-environment-ide:MCUXpresso-IDE
ASM Superprofi schrieb: > Für Mampfi: Da ich zu blöd bin zu kapieren, wie man ASM mit C Objekten > mischt, musste ich tatsächlich eine TFT Lib in ASM schreiben :(((((( > > ;) ?????
W.S. schrieb: >> Es gibt dafür die schöne Erfindung des Kapitels. > Das war zwar ein netter Spruch, aber ich würde dich dafür dazu > verdammen, einmal einen Kinetis MKE06xxx aufzusetzen, OHNE deren > Kinetis-Blabla-Studio verwenden zu dürfen. Hab ich gemacht. Überhaupt kein Problem. Hatte mich vorher anhand eines STM32 in ARM eingearbeitet (davor AVR). Alles im Selbststudium. Erst Kinetis L, dann später noch E. Die Kinetis E0x-Reihe ist so minimalistisch, die Dinger sind kein bisschen schwieriger als damals ein ATmega, das GPIO ist ab Reset schon eingeschaltet und die Peripheriefunktionen auf den Pins aktivieren sich bei Benutzung von selbst, genau so simpel wie beim AVR. Die Dokumentation ist sauber und übersichtlich aufgebaut, alles steht genau da wo man es vermutet und wo es auch hingehört: * Jede Peripherie hat ein eigenes Kapitel in dem alles erklärt wird, jedes Register und jedes Bit, teils auch mit Code-Beispielen oder Ablaufplänen für die Initialisierung oder die empfohlene Behandlung im Interrupt. * Und im Kapitel 3 ist aufgelistet wieviele von jeder Sorte auf diesem konkreten Chip instantiiert sind und wie die untereinander verschaltet sind (Mux-Tabellen, etc). * Alles was man zur Programmierung braucht steht übersichtlich in einem einzigen Dokument. Wenn man links das Inhaltsverzeichnis des PDF aufklappt findet man jede Information binnen Sekunden. Und hat man ein Kinetis Manual gesehen kennt man sie alle. Mir ist nicht klar warum Du immer wieder behauptest die Doku wäre schlecht, von der hervorragend organisierten Kinetis Doku könnten sich mancher andere ein Scheibe abschneiden. Das einzige was nervt (aber das ist bei allen anderen ebenfalls so) ist daß man tonnenweise unnötigen Schrott herunterladen und durchwühlen muss bis man irgendwo versteckt im hintersten Zipfel eines unförmigen "SDK" .zip versteckt hinter Tonnen von stinkendem HAL-Unrat die eigentlich wichtigen Sachen wie CMSIS-Header, Linkerscripte und Startup findet, aber das muss man ja pro CPU nur ein einziges mal machen, dann hat mans, und da bekleckern sich andere Hersteller auch nicht mit Ruhm, bei STM gehts diesbezüglich genauso unübersichtlich zu.
:
Bearbeitet durch User
Eine letzte Frage hätte ich noch bezüglich Atmega328, es gibt verschiedene Bezeichnungen bei den Chips, z.B. Atmega328, Atmega328p, Atmega328p-pu. Ziemlich verwirrend, was ist da der Unterschied bzw. spielt das überhaupt ne Rolle welchen ich zu Beginn nehme?
oleg schrieb: > Eine letzte Frage hätte ich noch bezüglich Atmega328, es gibt > verschiedene Bezeichnungen bei den Chips, z.B. Atmega328, Atmega328p, > Atmega328p-pu. Ziemlich verwirrend, was ist da der Unterschied bzw. > spielt das überhaupt ne Rolle welchen ich zu Beginn nehme? Und die wirklich letzte Frage, kann ich mit diesem Atmega328 das AVR Tutorial hier auf dieser Seite durcharbeiten? Davon abgesehen, dass ich hier im Form jede Menge Hilfe bekommen könnte.
oleg schrieb: > z.B. Atmega328, Atmega328p, > Atmega328p-pu. *P - “Picopower”, hat ein paar Powersave-Funktionen mehr als der ohne P. Die angehängten -PU etc. bezeichnen die Gehäusevarianten. Die findest du am Ende des Datenblatts erklärt (“Ordering Information” und “Packaging Information”). Wenn man sie weglässt, beschreibt man halt nur das generische Bauteil, ohne auf das Gehäuse einzugehen. > Ziemlich verwirrend, was ist da der Unterschied bzw. > spielt das überhaupt ne Rolle welchen ich zu Beginn nehme? Das Gehäuse dürfte sehr wohl eine Rolle spielen :), nicht jeder wird beispielsweise gleich einen ATmega328P-MU nehmen wollen.
Mampf F. schrieb: > Ja wahnsinn! Nee, nix Wahnsinn. Ich hatte vor Jahren mal den USB-Quellcode von Nuvoton auseinander genommen, weil der so unsäglich von Macros strotzte, daß man ne Krise davon kriegt. Als Ergebnis hab ich mir dann meinen eigenen USB-CDC-Treiber geschrieben und auf die Vorlage von Nuvoton gepfiffen. Die haben es nämlich auch nicht besser gemacht als all die Anderen (NXP, ST und so) und einen irren Haufen Kruscht eingebaut - insbesondere sowas wie Arrays variabler Länge von void Pointern. Klasse, sowas liebt unsereins über alle Maßen!! Ich krieg jetzt noch Pickel, wenn ich nur dran denke... W.S.
Bernd K. schrieb: > Die Dokumentation ist sauber und übersichtlich aufgebaut, alles steht > genau da wo man es vermutet und wo es auch hingehört: > > * Jede Peripherie hat ein eigenes Kapitel in dem alles erklärt wird, > jedes Register und jedes Bit, teils auch mit Code-Beispielen oder > Ablaufplänen für die Initialisierung oder die empfohlene Behandlung im > Interrupt. So langsam regen mich deine ständigen Behauptungen auf. Worüber schreibst du eigentlich? Ich hab den Eindruck, du schreibst über ein ganz anderes Produkt als ich. Also, ich schreibe zum Beispiel über "MKE02P64M40SF0RM.pdf", das ist das RefManual zu den MKE02Z16VLC4, MKE02Z32VLC4, MKE02Z64VLC4, MKE02Z16VLD4, MKE02Z32VLD4, MKE02Z64VLD4, MKE02Z32VLH4, MKE02Z64VLH4, MKE02Z32VQH4, MKE02Z64VQH4, MKE02Z16VFM4, MKE02Z32VFM4 und MKE02Z64VFM4. Dort gibt's ein Kapitel 11: Port Control (PORTS). Dort werden aber nicht die Ports und deren Verwendung erklärt, sondern lediglich das Glitchfilter, die Pullups, die Pulldowns und die Stromstärke (HDRIVE). Eigentlich würde das in das Kapitel 32: GPIO gehören. Die tatsächliche Port-Verwendung, also ob so ein Pin nun UART-TxD oder Counter-Clock oder I2C oder GPIO oder was sonst noch sein soll, wird weder in Kapitel 11 noch in Kapitel 32 geklärt. Dazu findet man NUR in "MKE02P64M40SF0.pdf", was das Datenblatt zu einigen der im RefManual behandelten µC ist, eine Tabelle. Geht so, zwar nicht schön, aber geht. Aber schauen wir mal dort rein und nehmen uns ein Pin heraus, z.B. PTB2. Das kann sein: PTB2(also GPIO), KBI0_P6(Keyboard-Interrupt), SPI0_SCK(SPI eben), FTM0_CH0(Timer Modul), ADC0_SE6(Analog). So! Wenn man jetzt PTB2 als GPIO benutzen will, aber eben auch den SPI-Modul und auch den Timer-Modul - natürlich auf anderen Ports, oder den Timer z.B. nur intern ohne I/O, wie stellt man jetzt die Funktion dieses PTB2 denn ein? Bei anderen Kinetis-Familien ist das so gehandhabt wie bei vielen µC von NXP und ST. Da gibt es HW-Register, wo man die gewünschte Port-Funktion hineinschreibt und fertig ist die Zuweisung. Aber bei der MKE-Reihe gibt es derartige Register eben NICHT. Verstehst du das endlich? Es gibt sie NICHT! Deswegen kann man den Portpins auch nicht dediziert ihre Funktion zuweisen, wie man das bei anderen Produkten kann. Das ist schlichtweg Bockmist der Sonderklasse. Bei meiner damaligen Anfrage an Freescale wurde mir geantwortet, daß man die Auswahl damit tätigt, daß man keine weiter rechts in der Tabelle des Datenblattes "MKE02P64M40SF0.pdf" (Seiten 32..33) stehende Peripherie aktiviert, denn es wird automatisch immer die Funktion dem Pin zugewiesen, die am weitesten rechts in der Tabelle steht. Klasse! Wenn ich nen Pin als GPIO benutzen will, bei dem z.B. auch UART0 aufgelistet ist, dann darf ich UART0 nicht aktivieren, weil sonst der Pin nicht mehr als GPIO benutzbar ist. Nun taucht UART0 mehrfach auf, hier sowohl auf PTB1 als auch auf PTA3 - und wo steht, wie man beim festlegen der Pins verfahren muß, auf denen man UART0 nicht haben will? UART0_TxD braucht man ja nur einmal und nicht auf allen dafür möglichen Pins. Die Antwort ist klar: Man muß für jedes Pin durch alle seine möglichen Verwendungen tingeln und in den dafür zuständigen Peripherie-Cores genau DIESE Verwendung ausschließen, z.B. indem man dort ein anderes Pin ansagt (falls man damit nicht an andere Setup's anrempelt) oder den Core eben irgendwie so einstellt, daß er eben genau DIESES Pin nicht benutzt. Im Klartext: Für die immer wiederkehrende Basis-Arbeit des Zuweisens der Funktionen für ein Port-Pin muß man immer wieder durch alle Kapitel des RefManuals sich durchquälen und dort Einstellungen vornehmen. Gilt aber nur, wenn man das weiß! In keiner Dokumentation zu dieser Familie ist das tatsächliche Verfahren zur Funktions-Auswahl beschrieben - man kann das allenfalls stückweise zwischen den Zeilen lesen. Dieses Verfahren ist (Damen mal bitte wegschauen) OBERSCHEISSE! Es geht nur dann passabel, wenn man brav das Konfigurations-Tool des Herstellers benutzt, weil man selber von Hand mit dem Konfigurieren des Chips graue Haare kriegt. Da ganze gleicht etwas dem Rubik-Würfel: Um eine Sache einzustellen, muß man an allen anderen Sachen zugleich mitdrehen - und das so lange, bis es denn endlich paßt. Nein, gerade bei dieser Kinetis-Familie sucht man sich tot in den Manuals, eben weil dort weder in der Hardware noch in der Dokumentation die Dinge dort und so sind, wo und wie sie hingehören. Natürlich riecht man den Zweck dahinter. Was ST mit Cube, Infineon mit Dave und andere Hersteller mit jeweils ihren Tools tun, das macht Freescale eben auch. So Bernd, jetzt bist du dran: Schildere doch einfach mal, wie man all den Portpins eines der genannten µC dediziert deren gewünschte Funktionen zuweist. Nach deiner Meinung geht das ja so einfach. W.S.
W.S. schrieb: > Bernd K. schrieb: >> Die Dokumentation ist sauber und übersichtlich aufgebaut, alles steht >> genau da wo man es vermutet und wo es auch hingehört: >> >> * Jede Peripherie hat ein eigenes Kapitel in dem alles erklärt wird, >> jedes Register und jedes Bit, teils auch mit Code-Beispielen oder >> Ablaufplänen für die Initialisierung oder die empfohlene Behandlung im >> Interrupt. > > So langsam regen mich deine ständigen Behauptungen auf. Worüber > schreibst du eigentlich? Ich hab den Eindruck, du schreibst über ein > ganz anderes Produkt als ich. > > Also, ich schreibe zum Beispiel über "MKE02P64M40SF0RM.pdf" Was stimmt bei Dir nicht? Bei jeder Gelegenheit meckerst Du rum wie Dir die Handbücher nicht passen aber jedesmal kommst Du wieder mit nem neuem MKE oder MKL an, diesmal ein MKE06. Warum hängst Du so sehr an Kinetis wenn sie doch so scheiße sind? Und wenn Dich tatsächlich jemand dazu zwingt warum merkst Du Dir nicht endlich mal die zwei oder drei Kapitelüberschriften die bei ALLEN Kinetis identisch lauten in denen immer wieder die selben 3 Sachen stehen nach denen Du immer und immer wieder wieder fragst und die man Dir jedesmal aufs Neue beantwortet und namentlich die Kapitel nennt und die Du jedesmal angeblich trotzdem wieder suchen musst wenn Du trotz tiefster Abneigung wieder mit dem nächsten Kinetis daherkommst der fast identisch aufgebaut ist wie der letzte und fast das selbe RefMan hat? Was ist los mit Dir? > Dort gibt's ein Kapitel 11: Port Control (PORTS). Dort werden aber > nicht die Ports und deren Verwendung erklärt, sondern lediglich das > Glitchfilter, die Pullups, die Pulldowns und die Stromstärke (HDRIVE). > Eigentlich würde das in das Kapitel 32: GPIO gehören. Im PORT Kapitel steht gleich am Anfang dick und fett daß deren IO über die GPIO-Register kontrolliert wird. Wer lesen kann ist klar im Vorteil. In den Blockschaltbildern ist das auch bebildert für die die weniger gut lesen können. Das ist bei allen Kinetis so, auch bei den letzte 12 über die Du Dich aufgeregt hast, und be jedem steht schwarz auf weiß im PORT-Kapitel daß IO über die GPIO-Register gemacht wird langsam sollte sich das im Hirn eingebrannt haben, meinst Du nicht? > Die tatsächliche > Port-Verwendung, also ob so ein Pin nun UART-TxD oder Counter-Clock oder > I2C oder GPIO oder was sonst noch sein soll, wird weder in Kapitel 11 > noch in Kapitel 32 geklärt. Dazu findet man NUR in > "MKE02P64M40SF0.pdf", was das Datenblatt zu einigen der im RefManual > behandelten µC ist, eine Tabelle. Geht so, zwar nicht schön, aber geht. Nein, das ist gelogen. Pinout und Alternate-Funktionen stehen dick und fett im Kapitel 10 Signal multiplexing and pin assignments (wie bei ALLEN Kinetis). Das ist das selbe PDF, man muss hier nicht nach dem Datenblatt suchen. Und das ist kein verstecktes Unterkapitel das man erst aufklappen müsste, das springt einen sofort an in der ersten Ebene. Mach die Augen auf / kauf Dir eine Brille (nichtzutreffendes streichen). > So! Wenn man jetzt PTB2 als GPIO benutzen will, aber eben auch den > SPI-Modul und auch den Timer-Modul - natürlich auf anderen Ports, oder > den Timer z.B. nur intern ohne I/O, wie stellt man jetzt die Funktion > dieses PTB2 denn ein? Im SIM->PINSEL stellt man das ein, das steht dick und fett und blau unterlegt (und verlinkt) gleich am Anfang des oben genannten Kapitels Signal multiplexing and pin assignments. Stellst Du Dich absichtlich so dumm? Bist Du ein Troll? > Aber bei der MKE-Reihe gibt es derartige Register eben NICHT. > Verstehst du das endlich? Es gibt sie NICHT! SIM->PINSEL. Wie oben erwähnt. > Wenn ich nen Pin als GPIO benutzen will, bei dem z.B. auch UART0 > aufgelistet ist, dann darf ich UART0 nicht aktivieren, Dann legst Du den UART0 halt eben auf die beiden Alternativpins, wo ist das Problem? > Im Klartext: Für die immer wiederkehrende Basis-Arbeit des Zuweisens der > Funktionen für ein Port-Pin muß man immer wieder durch alle Kapitel > des RefManuals sich durchquälen und dort Einstellungen vornehmen. Bullschit. Man nimmt die Tabelle mit dem Pinout (immer noch Kapitel 10 welches sich bereits in den Bildschirm eingebrannt haben sollte) und sucht sich die Pins für UART, SPI, ADC, oder was auch immer aus die man gerne verwenden will, trägt die getroffene Auswahl im PINSEL-Register ein und der Rest bleibt GPIO. Fertig. > Dieses Verfahren ist (Damen mal bitte wegschauen) OBERSCHEISSE! Bei AVR hat man das genauso gemacht, Sonderfunktionen liegen auch da auf festen Pins und wenn man z.B. den UART einschaltet krallt der sich seine beiden Pins von selbst, trotzdem hört man immer wieder AVR sei so einfach. Beim MKE funktionierts genauso. > Es geht > nur dann passabel, wenn man brav das Konfigurations-Tool des Herstellers > benutzt, weil man selber von Hand mit dem Konfigurieren des Chips graue > Haare kriegt Das erzähl mal den ganzen AVR-Programmierern hier dort geht das exakt genauso: erst sucht man sich die Pins mit den Sonderfunktionen raus die man für irgendwas braucht und der ganze Rest der übrig bleibt kann für GPIO verwendet werden. hat noch keiner graue Haare von bekommen und nach nem Konfig-Tool hab ich dort noch keinen schreien hören. Du solltest vielleicht das Hobby wechseln wenn Dir das so sehr zusetzt daß es schon die Haarfarbe angreift. > Da ganze gleicht etwas dem Rubik-Würfel: Um eine Sache > einzustellen, muß man an allen anderen Sachen zugleich mitdrehen - und > das so lange, bis es denn endlich paßt. Bei welchen "allen anderen" Sachen? Du sprichst in Rätseln. > Nein, gerade bei dieser Kinetis-Familie sucht man sich tot in den > Manuals, Also ich blende immer als erstes links das Inhaltsverzeichnis ein, dann finde ich Kapitel 3 oder Kapitel 10 (die beiden Kapitel die Du andauernd aufs neue suchst) binnen 2 Sekunden.
:
Bearbeitet durch User
Bernd K. schrieb: > Dann legst Du den UART0 halt eben auf die beiden Alternativpins, wo ist > das Problem? Daß eben auf den Alternativpins bereits etwas anderes zu liegen gekommen ist und daß man dann selbiges eben abwürgt, sofern UART0 in der Tafel eben weiter rechts steht. Kapierst du diese Umständlichkeit nun endlich? Man muß eben genau so, wie ich das geschrieben habe, durch alle Kapitel tingeln, um sich die Informationen mühsam zusammenzusuchen, die man braucht. Und es ist eben doch der Rubik-Würfel, wenn man zum Auswählen eines GPIO den USART erst mal auf nen Alternativport und den Timer auch auf nen Alternativport und den Weißdergeier auch noch auf seinen Alternativport verlegen muß und dann zusehen muß, was man dann mit den Alternativports anstellt, um sie sinnvoll benutzen zu können. Also genau wie du es auf deine Art umrissen hast, muß man bei diesen µC kreuz und quer im RefManual und im DB herumsuchen, um sich die Informationen zusammen zu klauben, die man braucht, um das Teil benutzen zu können. Stets und ständig steht eben was man braucht nicht dort, wo man es braucht, sondern woanders oder garnicht. Und warum ich gelegentlich drauf zurückkomme? Nun, ganz einfach: Weil eben die Chips und die Dokumente dazu von Freescale so schlecht sind wie sie sind. Schade eigentlich, der Preis hätte mich durchaus interessiert, aber in der Gesamtkalkulation ist es eben nur ein Posten von vielen. Aber so leicht lasse ich dich nicht davonkommen, da du ja den entsprechenden Ton angeschlagen hast. Also erkläre der lauschenden Gemeinde doch abschließend mal, wie man denn vorgeht, wenn man z.B. sämtliche Timer intern zu gebrauchen gedenkt und dennoch alle Portpins als GPIO zu benutzen gedenkt. Nur so als Beispiel zwecks Klarheit über die Vorgehensweise. W.S.
W.S. schrieb: > Man muß eben genau so, wie ich das geschrieben habe, durch alle Kapitel > tingeln, um sich die Informationen mühsam zusammenzusuchen, die man > braucht. Nein, muss man nicht, man muss * erstens planen welche Peripheriegeräte man zu nutzen gedenkt * zweitens dann in der Tabelle nachschauen auf welchen Pins die rauskommen und das in seinem Schaltplan entsprechend anschließen * drittens alles was übrig bleibt kann man als GPIO nutzen und das in seinem Schaltplan entsprechend anschließen. Fertig. Ich sehe nicht wozu man da durch irgendwelche Kapitel "tingeln" muss, alle möglichen Pinfunktionen für jeden einzelnen Pin stehen übersichtlich in der Pinout Tabelle, diese Tabelle ist alles was man dazu braucht.
W.S. schrieb: > Also erkläre der lauschenden > Gemeinde doch abschließend mal, wie man denn vorgeht, wenn man z.B. > sämtliche Timer intern zu gebrauchen gedenkt und dennoch alle Portpins > als GPIO zu benutzen gedenkt. Nur so als Beispiel zwecks Klarheit über > die Vorgehensweise. Dann schaltet man einfach keinen der PWM-Ausgänge ein, was auch nicht weiter schwer ist denn die sind ja per Default sowieso alle erstmal ausgeschaltet und wenn Du die Timerkanäle nur für interne Zwecke nutzt (Interrupt, DMA-Trigger, etc) hast Du ja nicht den geringsten Grund die PWM-Erzeugung einzuschalten. Dann bleiben die zugehörigen Pins auf GPIO weil nicht anderweitig genutzt.
Da ist es doch herrlich wenn die Hersteller Werkzeuge liefern mit denen man einfach so komplizierte Konfigurationen hinbekommt ohne die Manuals lesen zu müssen :-)))
JojoS schrieb: > Da ist es doch herrlich wenn die Hersteller Werkzeuge liefern mit denen > man einfach so komplizierte Konfigurationen hinbekommt ohne die Manuals W.S. ud ich streiten uns hier über einen KE06, der ist ungefähr so kompliziert wie ein ATMega und konfiguriert sich auch so ähnlich: Schaltest Du die PWM-Erzeugung an kannst Du den betreffenden Pin (der im Pinout so beschriftet ist) nicht mehr als GPIO nutzen. Schaltest Du den UART an krallt der sich seinen TX-Pin. Schaltest ihn wieder ab ist der Pin wieder GPIO. Dafür hat noch keiner ein Konfig-Tool gebraucht, da gibts nämlich überhaupt nix zu konfigurieren, das geht automatisch. Da muss man nur in der Tabelle nachschauen welche Peripherie auf welchen Pins rauskommt. Optimal für ängstliche AVR-Umsteiger, da fühlt man sich gleich wie zuhause.
:
Bearbeitet durch User
Naja, so Tools wie Cube von ST meckern schon wenn etwas nicht zusammen passt. Wenn man das zur Laufzeit umkonfiguriert können die natürlich auch nicht helfen, aber einfacher als ein Telefonbuch dickes Manual durch zu lesen sind die Tools schon. Ansonsten noch ein entspanntes Wochenende.
JojoS schrieb: > aber einfacher als ein Telefonbuch dickes Manual > durch zu lesen sind die Tools schon. Es reicht für den Anfang alle Kapitel wegzulassen die Funktionen beschreiben die man gar nicht nutzen will. Die sind nämlich allesamt per Default ausgeschaltet und kommen einem nicht in die Quere. Man liest die algemeinen Kapitel am Anfang die das Produkt beschreiben und einen Überblick verschaffen, das sind vielleicht 100 Seiten (im Taschenbuchformat luftig gesetzt und mit Diagrammen angereichert, nicht im Telefonbuchformat), und vom Rest nur noch gezielt das was man braucht.
:
Bearbeitet durch User
Sehe ich auch so, trotzdem erwartet man zB das Pins per default gpio sind aber nach Reset zB debug pins sind. Bin ich vor Jahren beim mega32 drauf reingefallen und das gibts bei den ARM heute noch genauso. Gut wenn man es vorher gelesen hat, aber in welchem Kapitel fängt der blutige Angänger an?
Johannes S. schrieb: > Sehe ich auch so, trotzdem erwartet man zB das Pins per default gpio > sind aber nach Reset zB debug pins sind. Beim Kinetis E (über den ich mich oben mit WS stritt) ist das genau so:
1 | After reset, the shared peripheral functions are disabled so that the pins |
2 | are controlled by the parallel I/O except PTA4, PTA5, PTB4 and PTC4 that are |
3 | default to SWD_DIO, SWD_CLK, NMI and RESET function. All of the parallel I/O |
4 | are configured as high- impedance (Hi-Z). |
> Bin ich vor Jahren beim mega32 > drauf reingefallen und das gibts bei den ARM heute noch genauso. Worauf genau bist Du reingefallen? > Gut > wenn man es vorher gelesen hat, aber in welchem Kapitel fängt der > blutige Angänger an? Bei Kapitel 1, bis der allgemeine Teil vorbei ist, der ganze Rest ist Nachschlagewerk.
Bernd K. schrieb: > Worauf genau bist Du reingefallen? Der berühmte Port C bei dem einige Bits nicht funktionierten (weil sie per default Jtag sind). Das war früher wöchentliches Thema wie 'LED ohne Wiederstand' und 'mein 7805 glüht'. Aber auch da wurde sie hier schon geholfen.
Johannes S. schrieb: > Der berühmte Port C bei dem einige Bits nicht funktionierten (weil sie > per default Jtag sind). Ja, für solche Sachen kann man das Manual immer gut gebrauchen. Es gibt halt leider noch keine andere Möglichkeit wie man das Wissen schneller ins Gehirn uploaden kann. Ich würd mir statt nem riesigen Datenblatt auch lieber den zugehörigen Braindump besorgen und dann 5 Sekunden lang den Stick ins Ohr stecken ums zu laden, aber das geht leider noch nicht.
Gut, ich habe mitgelesen (jeden einzelnen Beitrag) und bin zu dem Schluss gekommen es mit dem ARM auf mich zu nehmen (STM32F0Discovery). Hauptaugenmerk wird aber zuerst das AVR Tutorial mit einem AVR sein. In den Cortex werde ich mich dann parallel einarbeiten, ganz zwanglos und ohne Stress :-) Danke einem jeden einzelnen von euch, eure Meinungen waren sehr hilfreich für mich.
oleg schrieb: > Danke einem jeden einzelnen von euch, eure Meinungen waren sehr > hilfreich für mich. Wir haben zu danken ... Es ist normalerweise die Regel, dass Gäste - nachdem die eine Diskussion angestoßen haben - nie wieder die Antworten lesen ... Gut, dass das alles nicht umsonst war xD
Das mit den Parallel einarbeiten würde ich lassen. Die Unterschiede sind einfach zu groß. Am besten erst mal den AVR verstehen dann zum ARM übergehen. Ein ARM ist einfach zu komplex um als Anfänger das Registerwerk zu verstehen.
Marco H. schrieb: > das Registerwerk zu verstehen Das „Registerwerk“ ist ja nun eher nicht das Problem, das ist kaum schwieriger zu verstehen als das beim AVR (und überdies völlig durch den C-Compiler versteckt). Schwieriger ist da eher das „Drumrum“ zur CPU, also die Erzeugung der diversen Takte, der Interruptcontroller und dergleichen. Einen Teil dieser zusätzlichen Komplexität findet man auf der AVR-Seite allerdings auch bereits bei den Xmegas vor, auch dort ist der Einstieg ein bisschen komplexer als bei den Standard-AVRs.
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.