Mein Wunsch wäre es auf dieser Plattform ein Tutoriell für die “moderneren” Prozessoren zu finden. Das AVR Tutoriell für C und ASM ist ein Aushängeschild des Forums, welches hier sicherlich viele hergelockt hat. Es wäre an der Zeit, sowas für STM32, LPC… & Co hier zu präsentieren. Damit meine ich nicht verlinkungen auf irgendwelche Seiten sondern ein eigenes Kapitel im Stil der C und ASM Tuts. Auch wenn es dafür notwendig wäre (glaube ich zumindest), dass dafür eine Festlegung auf eine Entwicklungsumgebung notwendig ist wäre es eine große zeitgemäße Bereicherung für diese Seite. Ich bin leider nicht in der Lage da mehr als mein Wunsch danach beizusteuern. Inzwischen finden sich hier einige Spezialisten, die mit diesen µC gut vertraut sind., die fachlich in der Lage wären das umzusetzen. Ich weiß, hier gibt es diverse nützliche Fragmente zu diesen Thema, aber eine „gebündelte Form“ fänd ich echt toll.
Das Datenblatt des Proztessors beschreibt doch die Peripherie... Wenn man einen AVR bedienen kann, kann man auch "komplexere" Peripherie benutzen. Die Prinzipien sind die selben.
Fred F. schrieb: > Mein Wunsch wäre es auf dieser Plattform ein Tutoriell für die > “moderneren” Prozessoren zu finden. Das AVR Tutoriell für C und ASM ist > ein Aushängeschild des Forums, welches hier sicherlich viele hergelockt > hat. Es wäre an der Zeit, sowas für STM32, LPC… & Co hier zu > präsentieren Warum reicht dir nicht das AVR-Tutorial? Völlig ernsthaft, soviel anders ist das Programmieren für ARM nicht. Man muß C können und wissen was es prinzipiell an Parameter für eine I2C etc.-Schnittstelle gibt. Die mnemnics für die konkreten Register entnimmst der Doku resp. Headerdateien, Prozessorspezalitäten dem Datenblatt. Kannste einen µC kannste (ungefähr) alle.
Bitwurschtler schrieb: > Kannste einen µC kannste (ungefähr) alle. Na ja, der Teufel steckt schon im Detail... Beim AVR ist die Welt homogener, und war es noch mehr als die Wikiartikel entstanden sind. Den 'ÄRM' gibt es ja nicht, nur den Core von ARM und dazu viele Hersteller die diesen Kern in Lizenz in ihre Produkte einbauen und mit ihrer Peripherie kombinieren. Daher haben alle Peripherieteile andere Register und irgendein übersehenes Bit kann dich stundenlange Fehlersuche kosten. Und um Kunden zu gewinnen und zu binden bieten fast alle Hersteller zusätzliche Software mit Compiler, IDE und weiteren Configtools. Die einen mögen die, die anderen nicht. Ich habe mit LPCXpresso angefangen und gute Erfahrungen gemacht, das passt aber nur zu NXP LPC Prozessoren. Möchtest du STM einsetzen brauchst du was anderes. So ist die ARM Welt viel mehr Multi Kulti und ich bezweifele das es hier je ein Tutorial wie für den AVR geben wird.
Fred F. schrieb: > Es wäre an der Zeit, sowas für STM32, LPC… & Co hier zu präsentieren. Mit oder ohne CMSIS HAL StdPeriph CubeMX ...? Für welchen SoC konkret? Bei AVRs gibt's ja nicht soo die Unterschiede. Oder doch nur für den Cortex-M3? Was ist mit dem -M4, oder -M0? Mag ja sein, dass alle ARMs vom gcc unterstützt werden, aber allein eine LED (aus dem Nichts) blinken zu lassen ist kompliziert genug, dass man es nicht universell in einem Tutorial abhandeln kann. Du kannst natürlich 5 Tutorials für die großen Familien schreiben...
S. R. schrieb: > Oder doch nur für den Cortex-M3? Was ist mit dem -M4, oder -M0? Das ist ja fast egal, die Unterschiede sortiert sowieso weitgehend der Compiler aus. Auch die Bitbreite spielt da praktisch keine Geige, die Addition zweier 32-bit-Zahlen ist nach wie vor „a + b“, und das konnte man schon beim AVR so schreiben. Was aber (wie schon geschrieben wurde) eben nicht egal ist, sind die zahllosen Unterschiede in der Peripherie. Selbst innerhalb eines Herstellers muss das ja keineswegs einheitlich sein (Beispiel Atmel: die SAM3 und SAM4 folgen da den älteren SAM7, SAMD und neuere dagegen nutzen weniger dinosaurierhaft anmutende Peripherals vom AVR32), und zwischen den Herstellern ist schon gar nichts gleich. So gesehen wird es nicht das „32-Bit-Tutorial“ geben können, sondern bestenfalls eins für STM32F<wasauchimmer>, eins für LPC<wasauchimmer>, eins für SAM4, eins für SAMD/SAML etc. pp.
Jörg W. schrieb: > S. R. schrieb: >> Oder doch nur für den Cortex-M3? Was ist mit dem -M4, oder -M0? > > Das ist ja fast egal, die Unterschiede sortiert sowieso weitgehend > der Compiler aus. Ganz mein Reden, kannste C für einen µC, kannste es für alle. Jörg W. schrieb: > Was aber (wie schon geschrieben wurde) eben nicht egal ist, sind die > zahllosen Unterschiede in der Peripherie. So wild unterschiedlich sind vielleicht die Details, aber nicht das prizipielle Vorgehen bei der Periphereal-Programmierung: -Parameter setzen -ISR - Peripheral starten und mit Daten füttern Da ist ein ARM-SPI npripheral nicht viel anders als ein AVR-SPI-Peripheral. Man muss halt die prinzipiellen Parameter (Datenrate, aktive Flanke,...) verstanden haben. Aber vielleicht will der TO kein Verständniss, sondern eine dummy-anleitung ala "Schreibe diesen Code mit den magischen Code ab und Wunder werden geschehen". Das ist natürlich zweckfrei und wird den Namen Tutorial nicht gerecht. Besser wäre es, das AVR Tutorial ggf so umzuschreiben das auch die ARM-Programmierer mehr davon haben. Also erst mal allgemein das Vorgehen an diesem Peripheral erklären, erst dann die magischen Registersettings.
Bitwurschtler schrieb: > Da ist ein ARM-SPI npripheral nicht viel anders als ein > AVR-SPI-Peripheral. Für SPI oder UART hast du Recht. Bei den Parallelports, Externinterrupts oder Timern sind dagegen die Unterschiede oft gravierend. So verteilt STM32 die Interruptnummern quer über den Port auf die Bitnummern, PA1 und PC1 generieren also den gleichen Interrupt, während wohl ziemlich alle anderen einen Interrupt pro Port haben, also PA, PB etc. Auch hat STM32 nur 16-bit-Ports, Atmel's ARMs dagegen durchweg 32-bit-Ports (die natürlich nicht immer vollständig mit Pins bestückt sind).
Jörg W. schrieb: > So verteilt STM32 die Interruptnummern > quer über den Port auf die Bitnummern, PA1 und PC1 generieren also > den gleichen Interrupt, während wohl ziemlich alle anderen einen > Interrupt pro Port haben, also PA, PB etc. Werden diese über die - ich nenns mal ISR-Compiler-Makros- abgefangen oder nicht? Wieviel muss ein Programmierer von der physikalsichen Implementierung des Interruptsystem wissen? Das kann sich doch der Compiler auseinanderfriemeln wie der IRQ zu seinem ISR kommt. > Auch hat STM32 nur > 16-bit-Ports, Atmel's ARMs dagegen durchweg 32-bit-Ports (die natürlich > nicht immer vollständig mit Pins bestückt sind). Das sollte doch mit der Verwendung des richtigen Datentyps abgefangen sein?! Ja zu einer Erweiterung eines 8bit Tutorials zu einem 32bit gehört eine Betrachtung hierzu dazu, sollte aber nicht den Aufwand für rin neues Tutorial from the scratch sein.
Bitwurschtler schrieb: > Wieviel muss ein Programmierer von der physikalsichen > Implementierung des Interruptsystem wissen? Das kann sich doch der > Compiler auseinanderfriemeln wie der IRQ zu seinem ISR kommt. Es ist nicht Aufgabe des Compilers, das Interruptsystem auseinanderzufriemeln. Welche Interrupts wie über die verschiedenen Einheiten gemeinsam genutzt werden, kann der Compiler nicht wissen. Der weiß nur, dass da ein "INT xx" gefeuert hat - und es ist seine Aufgabe, den von dir vorgegebenen Handler aufzurufen. Das Problem ist nicht der ARM-Core (zumindest im Normalfall nicht). Das Problem ist die Peripherie, und da gilt "kennste eine, kennste alle" überhaupt nicht.
:
Bearbeitet durch User
S. R. schrieb: > Das Problem ist nicht der ARM-Core (zumindest im Normalfall nicht). Das > Problem ist die Peripherie, und da gilt "kennste eine, kennste alle" > überhaupt nicht. Klar gilt das, kennste I2C vom AVR weisste auch wie I2C an einem ARM funktioniert. Ebenso PWM,SPI,CTC, ... . Musst halt nur im Datenblatt/Header die konkreten bits/addressen raussuchen. Und eigentlich nicht mal das, das generiert dir die KlickiKacki IDE des Herstellers automatisch. Oder nochweiter abstrahiert lässte ein Linux auf dem µC laufen dann greifste über den devicetree zu und musst garnix von Peripheral wissen.
Bitwurschtler schrieb: > Klar gilt das Wenn du's besser weißt, dann bleib' doch bei deiner Meinung. Aber es sollte dir schon seltsam vorkommen, wenn dir auf der Autobahn nur noch Geisterfahrer entgegekommen … Praktisch jeder in diesem Thread erzählt dir, dass deine stark vereinfachte Weltsicht so nicht zutrifft, aber du wiederholst sie ad nauseum.
Bitwurschtler schrieb: > Klar gilt das, kennste I2C vom AVR weisste auch wie I2C an einem ARM > funktioniert. Unfug. Schau dir mal die Timer vom Atmega32, STM32F107 und SAM3X im Detail an. Schau dir mal die GPIOs vom Atmega32, STM32F107 und SAM3X im Detail an. Und bis dahin sei still.
Bitwurschtler schrieb: > Aber vielleicht will der TO kein Verständniss, sondern eine > dummy-anleitung ala "Schreibe diesen Code mit den magischen Code ab und > Wunder werden geschehen". Das ist natürlich zweckfrei und wird den Namen > Tutorial nicht gerecht. Dann würde ich mbed OS empfehlen https://www.mbed.com/en/platform/mbed-os/. "ARMiger" geht nicht, da von ARM selber, und mit dem 1-Klick-Import von Code in den Online-Compiler muss man nicht einmal Copy&Paste machen. Damit man weiß wo man klicken kann gibt es ein Kochbuch https://developer.mbed.org/cookbook/Homepage Die eigentliche Hardware ist soweit abstrahiert, dass ein Haufen Boards mit unterschiedlichen Cortex-M unterstützt wird https://developer.mbed.org/platforms/. Alles natürlich 100% Buzzword-Bingo geeignet. Cloud, IoT, Online-Compiler in der Cloud, Open-Source, sicher, Community-unterstützt ... Ehrlich gesagt, da kann man auch gleich Arduino nehmen.
S. R. schrieb: > Schau dir mal die Timer vom Atmega32, STM32F107 und SAM3X im Detail an. > Schau dir mal die GPIOs vom Atmega32, STM32F107 und SAM3X im Detail an. Selbst das „SPI ist doch überall gleich“: . AVR: manuelles Chipselect . SAM3/4: automatisches Chipselect, kann man auch nicht einfach ignorieren . STM32F4: manuelles Chipselect
:
Bearbeitet durch Moderator
S. R. schrieb: > Bitwurschtler schrieb: >> Klar gilt das, kennste I2C vom AVR weisste auch wie I2C an einem ARM >> funktioniert. > > Unfug. > > Schau dir mal die Timer vom Atmega32, STM32F107 und SAM3X im Detail an. > Schau dir mal die GPIOs vom Atmega32, STM32F107 und SAM3X im Detail an. Ja klar, ich schreib von I2C und du räts mir Timer und GPIO's anzuschauen - is wohl für dich das selbe Hardwarevodoo- > > Und bis dahin sei still. Hab ich. Und nun? Ich hab mir auch die weit über die µC Qualitäten hinaus konfigurierbarenen GPIO's der FPGA angeschaut. Und bleibe dabei. Kennst du ein Peripheral eines µC richtig, ist man auch ohne spezielles Typ-Tutorial in der Lage das analoge Peripheral eines andernen µC zu programmieren. Liegt vielleicht an einer Ausbildung in den 90igeren in der nicht jeder uC idiotengerecht aufbereitet einzeln filetiert und runter psalmodiert wurde sondern Wert auf das Erkennen von Gemeinsamkeiten gelegt wurde. Da gabs auch mehr "breitbandige" Literatur über Computerarchitektur, die in einem Rutsch E/A Schnittstellen und Kleinkram abhandelten, egal ob Intel oder Zilog. Ist letzlich immer aus dem selben Grundelementen (digitale Schaltungstechnik) zamgestrickt. Aber mancher findet den Wald vor lauter Bäumen nicht ....
Jörg W. schrieb: > Selbst das „SPI ist doch überall gleich“: > > . AVR: manuelles Chipselect > . SAM3/4: automatisches Chipselect, kann man auch nicht einfach > ignorieren > . STM32F4: manuelles Chipselect Ja und, hardwaretechnisch ist es dasselbe - Chipselect eben, Auswahl eines Kommunikationsendpunktes am Bus. Hat man das einmal kapiert, erklären sich die Implementierungsunterschiede von selbst.
Bitwurschtler schrieb: > Hat man das einmal kapiert, erklären sich die > Implementierungsunterschiede von selbst. Das ändert doch aber nichts daran, dass man für jeden dieser Controller die Bedienung neu lernt. Natürlich kann man das, das angefragte Tutorial soll jedoch wohl zumindest einen Teil davon abnehmen, indem es in konzentrierterer Form aufbereitet ist als das detaillierte Datenblatt. Nicht mehr, aber auch nicht weniger. Wenn man deine Argumentation logisch zu Ende führt, dann müsste es ja völlig genügen, dass man die Wirkungsweise eines Transistors verstanden hat. Aus dem sind ja die Gatter aufgebaut, und daraus dann wieder die ICs. Hat man den Transistor nur richtig verstanden, kann man jeden Controller programmieren …
Jörg W. schrieb: > Bitwurschtler schrieb: >> Hat man das einmal kapiert, erklären sich die >> Implementierungsunterschiede von selbst. > > Das ändert doch aber nichts daran, dass man für jeden dieser Controller > die Bedienung neu lernt. Nein, wer bei jedem Controller bei Null anfängt, der macht was grundfalsch. So wie der japanische Schüler der die Additionsreihen wie Schriftzeichen lernt (Steht links "1+2" muss ich rechts "3" schreiben) und dann bei einer Addition auserhalb dieser Reihe wie "100 + 2" völlig überfordert ist (soll es wirklich geben). > Natürlich kann man das, das angefragte > Tutorial soll jedoch wohl zumindest einen Teil davon abnehmen, indem > es in konzentrierterer Form aufbereitet ist als das detaillierte > Datenblatt. Nicht mehr, aber auch nicht weniger. Genau das -einiges von 32bit µC-Lernen abnehmen- kann auch das bestehende AVR Tutorial. Nämlich, das was gleich ist Grundlagen SPI, Timer, GPIO-Konfiguration, Funktion von PullUps,..)) Deshalb auch der Vorschlag das bestehende Tutorial in didaktische Schritte runterzuskalieren (falls nötig) damit die Gemeinsamkeiten zu den 32bit deutlich werden. Da brauchts kein neues Typspezif. Tutorial. Bei mir hinterlässt der TO den Eindruck als sind µC generell Neuland für ihn. Wenn dem so is,t dann rate ich die 32bitter auf später zu schieben und erstmal AVR mit dem Tutorial zu pauken. Hat er anhand diesem die Grundlagen verstanden, kann er sich mit dem Datenblatt auch die Spezifika des 32bit erarbeiten. > Wenn man deine Argumentation logisch zu Ende führt, dann müsste es > ja völlig genügen, dass man die Wirkungsweise eines Transistors > verstanden hat. Aus dem sind ja die Gatter aufgebaut, und daraus > dann wieder die ICs. Hat man den Transistor nur richtig verstanden, > kann man jeden Controller programmieren … Du hast mich nicht verstanden oder verstehst mich absichtlich falsch mglw. um mich lächerlich da stehen zu lassen. Meine Argumentation ist folgende: Es genügt völlig die Mikrocontrollerprogrammierung an einer µC-Reihe grundlegend zu verstehen, beispielsweise Atmel AVR. Und dazu sollte man auch ein gutes Tutorial heranziehen. Es ist dannach, wenn man die AVR-Programmierung verstanden hat, völlig unnötig ein Tutorial im gleichen Detailierungsgrad für eine weitere µC-Reihe einzufordern, weil sich darin viele Bereiche wiederholen - die selben Grundlagen (Was ist SPI? Welche Parameter kennt es? ...)
Bitwurschtler schrieb: > Es ist dannach, wenn man die AVR-Programmierung verstanden hat, völlig > unnötig ein Tutorial im gleichen Detailierungsgrad für eine weitere > µC-Reihe einzufordern, weil sich darin viele Bereiche wiederholen Das mag sein. Andererseits gibt es eine Reihe anderer Dinge bei den 32-Bittern (bereits bei den Xmegas), die es beim AVR nicht gab: das Taktsystem muss man sinnvoll initialisieren, und man muss sich um die Prioritäten von Interrupts kümmern. Auch den Umgang mit der DMA kann man gut an ein oder zwei Beispielen aufbereiten. Weiterhin ist die GCC-Toolchain nicht so schön „aus einem Guss“ wie beim AVR: praktisch jeder bringt seinen eigenen mehr oder minder schlechten Startup-Code und Linkerscript dort mit. Eine einfache Kommandozeile wie
1 | avr-gcc -mmcu=atmega8 -Os -o led.elf led.c |
tut's dort daher nicht. Auch dies könnte man in einem Tutorial durchaus sinnvoll aufbereiten, ohne dass sich auch nur das geringste mit dem AVR-Tutorial doppeln würde.
Jörg W. schrieb: > Bitwurschtler schrieb: >> Es ist dannach, wenn man die AVR-Programmierung verstanden hat, völlig >> unnötig ein Tutorial im gleichen Detailierungsgrad für eine weitere >> µC-Reihe einzufordern, weil sich darin viele Bereiche wiederholen > > Das mag sein. Das ist so! > Andererseits gibt es eine Reihe anderer Dinge bei den 32-Bittern > (bereits bei den Xmegas), die es beim AVR nicht gab: das Taktsystem > muss man sinnvoll initialisieren, und man muss sich um die Prioritäten > von Interrupts kümmern. Auch den Umgang mit der DMA kann man gut an > ein oder zwei Beispielen aufbereiten. Ja, es gibt Themen aus dem Bereich Computerarchitektur, die sich nicht im AVR-Tutorial finden lassen. Die würde ich aber nicht in einem Cortex/TMS0320x/DragonBall/etc. Tutorial abgehanmdelt sehen. Sondern in einem "Tutorial zu µC advanced" , das dann typunabhängig die Baureihenunabhängigen Grundzüge von DMA, Clock-Trees, Nested IRQ's etc behandelt. So einen allgemeinen Ansatz scheint aber der TO nicht im Sinn zu haben, der will sein spezielles Süppchen, > Weiterhin ist die GCC-Toolchain nicht so schön „aus einem Guss“ wie beim > AVR: praktisch jeder bringt seinen eigenen mehr oder minder schlechten > Startup-Code und Linkerscript dort mit. Eine einfache Kommandozeile wie > avr-gcc -mmcu=atmega8 -Os -o led.elf led.c > tut's dort daher nicht. Auch dies könnte man in einem Tutorial > durchaus sinnvoll aufbereiten, ohne dass sich auch nur das geringste > mit dem AVR-Tutorial doppeln würde. Nach meiner Erfahrung ist so eine allgemeine 32bit µC Toolchain nicht existent oder verbreitet, da hat jeder Hersteller seine eigene GUI, daher kann es ein solches 32bit Tutorial nicht geben. Sondern ein Tutorial für Dave, NXpresso, Xilinx mikroblaze-SDK. etc.. aber darauf wurde oben schon hingewiesen. Die Gemeinsamkeiten die es gibt liegen in den prinzipiellen C-konstrukten für µC wie Vereinbarungen wie Bitoperationen zu schreiben sind, Inline-Assenbler, etc. Ob das hiesige AVR tief genug auf hardwarenahes C-Programmieren eingeht, kann ich nicht sagen. Aber auch hier bestünde meiner Meinung nach die bessere Lösung in Erstellung eines universalen Textes und beispielhaftes Vertiefen/Verweisen auf konkrete Implementierungen.
Bitwurschtler schrieb: > Nach meiner Erfahrung ist so eine allgemeine 32bit µC Toolchain nicht > existent oder verbreitet, Kann man so nicht sagen. Wir compilieren generell hier SAM4, SAMR, STM32F4 alle mit der normalen GCC-Toolchain (arm-none-eabi-gcc). Der Compiler und Linker und auch die newlib sind dabei identisch. Niemand schreibt einem vor, dass man die jeweiligen durch die Hersteller gelieferten Versionen der Tools benutzen müsste, und in einem Projekt, welches auf vielen verschiedenen Architekturen lauffähig sein soll, kann man irgendwelche Kinkerlitzchen der Hersteller-IDEs ohnehin nicht gebrauchen. Da gibt's dann ein plattformunabhängiges Buildsystem, im einfachsten Falle eben Makefiles.
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.