Ich beschäftige mich mit dem ARM Cortex M4, aber auch mir AVR-Mega und -Tiny um einen Einstieg in die Welt der Mikrocontroller zu meistern. PIC hat mich eher abgeschreckt, fand ich alles ziemlich undurchsichtig. Wo seht ihr Bereiche in denen ARMs den AVRs den Rang ablaufen könnte? Wo haben die AVRs klare Vorteile zu den ARMs?
Oje, als ob dies Frage zum ersten Mal hier gestellt würde. Du sitzt immer noch an den Grundlagen, oder? Versuch es doch auch mal mit einer Suche im Forum. Beitrag "Re: Arduino - bringt's das ?"
ARM Cortex: + 32Bit, + Speed/Rechenleistung + Memory, + Peripherie/Schnittstellen o freie Compiler Toolchain (am ehsten brauchbar CooCox) - Komplex (nicht für Einsteiger) AVR (8Bit): + Einfach (für Einsteiger) + freie Compiler Toolchain (AVR-GCC: Eclipse mit Plugin oder AVR-Studio) o Peripherie/Schnitstellen - Speed/Rechenleistung (falls das wichtig ist)
Martin Bauer schrieb: > Ich beschäftige mich mit dem ARM Cortex M4, aber auch mir AVR-Mega und > -Tiny um einen Einstieg in die Welt der Mikrocontroller zu meistern. PIC > hat mich eher abgeschreckt, fand ich alles ziemlich undurchsichtig. > > Wo seht ihr Bereiche in denen ARMs den AVRs den Rang ablaufen könnte? > > Wo haben die AVRs klare Vorteile zu den ARMs? Zum Einstieg mit nem Cortex M4? Uff! Das ist aber ne harte Droge. Bin selbst Anfänger und wenn ich die 176 Seiten Datenblatt des ATTiny sehe, dann denke ich mir, "Na ja!" Der ATmega328 hat dann schon über 500 Seiten Datenblatt. Ich bin gespannt und werde diesen Thread sehr gerne lesen. Etwas kann ich dazu schon sagen. Das Preis/Leistungsverhältnis ist beim Cortex wohl besser. Ich hab so ein kleines Board von ST (16 Euro), da ist ist zwar nur ein kleiner M drauf, damit (soll) man schon irre viel machen können.
Hi Martin, meiner Meinung nach, ist zum Einstig ein AVR besser, da du nicht gleich bis zum Hals mit dingen zugeschüttet wirst. Die AVRs haben von allem etwas weniger als die ARM, weniger Timer, weniger Register, usw. Fang mit nem ATmega8 an, wenn du verstanden hast wie da die Timer, SPI, U(S)ART, usw. funktioniert, dann kannst du auch mit nem ATmega2560 umgehen, und dann ist der Sprung zum ARM nicht mehr soweit. Erstmal mit nem Polo anfangen, dann in den Audi und zum Schluss der Porsche ;) Soweit meine Meinung. Grüße
Kaj schrieb: > Fang mit nem ATmega8 an Dass hier alle immer noch den ATmega 8 anführen. Der ist mittlerweile teurer als ein ATm238 (bei guloshop für 2 Euro) und 88,168,328 sind ja die Nachfolger. Also warum nicht mit einem aktuellen anfangen. Gibts auch billig als Arduino.
Wenn ich heute nochmal anfangen würde, würde ich direkt auf ARM setzen. Natürlich sind bspw. die STM32F4 sehr komplex (die Referenz nur für die Peripherie hat schon über 1300 Seiten) - deutlich komplexer als AVRs. Aber: Niemand zwingt einen, direkt alles verwenden. Man fängt also auch dort einfach mit einer blinkenden Leuchtdiode an. Die Initialisierung der Ports ist aufgrund der Möglichkeiten natürlich umfangreicher, aber z.B. mit der ST-Bibliothek nicht so viel schwerer, zumal hier im Forum viele Beispiele und auch Tutorien zu finden sind. Von da aus hangelt man sich dann vielleicht zu den ersten Timern weiter und macht sich mit den Interrupts vertraut usw. Wenn man sich anfangs die Doku ansieht, denkt man natürlich: "Ach Du Sch...." :-) Preislich sind die 32-Bitter mittlerweile in denselben Regionen wie AVRs - bei ganz anderen Möglichkeiten! Passende Entwicklungsboards bekommt man hinterhergeschmissen, ansonsten gibt es sehr preiswerte Adapterplatinen für die SMD-Bausteine und sogar schon einige ARMs im DIL-Gehäuse. Chris D.
Frank O. schrieb: > Dass hier alle immer noch den ATmega 8 anführen. Der ist mittlerweile > teurer als ein ATm238 (bei guloshop für 2 Euro) und 88,168,328 sind ja > die Nachfolger. Also warum nicht mit einem aktuellen anfangen. Ja bitte :-) Der Mega328 ist bei Segor sogar billiger als der 168. Und die haben so viele schöne Sachen, die der olle Mega8 nicht vorweisen kann: Pinchange Interrupt, 3 PWM fähige Timer, bis zu 32k Flash....
Also ich habe mit den Tiny/Mega angefangen, über XMega zum Cortex F4. Das Ding ist schon hart, aber auch echt cool! Trotzdem, fürs Hobby bleibe ich bei den Tiny/ Mega AVRs. Sind doch etwas umgänglicher... Grundsätzlich sollte man mit dem Controller ein Problem lösen, nicht den Controller zum Problem machen ;) Ingo
Matthias Sch. schrieb: > Frank O. schrieb: >> Dass hier alle immer noch den ATmega 8 anführen. Der ist mittlerweile >> teurer als ein ATm238 (bei guloshop für 2 Euro) und 88,168,328 sind ja >> die Nachfolger. Also warum nicht mit einem aktuellen anfangen. > > Ja bitte :-) Der Mega328 ist bei Segor sogar billiger als der 168. Und > die haben so viele schöne Sachen, die der olle Mega8 nicht vorweisen > kann: Pinchange Interrupt, 3 PWM fähige Timer, bis zu 32k Flash.... Eben! Genau das meine ich. Wenn jemand nun ein Buch liest oder ein Tutorial liest, dann denkt er zunächst, dass er unbedingt einen Atm8 nehmen muss, weil er ja die Beispiele nachbauen will. Erst das Wissen über die Nachfolger (und das kommt leider viel später) bringt ihn mit alten Büchern (da könnten die in den neuen Auflagen im Titel auf die neueren µC verweisen) auf heutigem Stand. @Chris: Danke für deine Sichtweise! Ich überlege auch ziemlich schnell auf Cortex umzusteigen. Mich schreckt nur dieses SMD Gefummel ab. Bei Giga (ehemals Siemens) hatte ich vor einigen Monaten in der Reparaturabteilung mal sehen wollen wie die Frauen das da löten (war früher so), aber selbst da machen die das mittlerweile nur noch mit Automaten. Die Platine die ich dort in der Hand hatte, da waren schon Bauteile drauf und die sind so winzig gewesen, dass ich sie kaum noch erkennen konnte. Verlockend ist natürlich das man nichts mehr bohren muss und man wird auf Dauer nicht an SMD vorbei kommen, weshalb dann so ein Cortex wieder deutlicher denkbar wird. Und es ist jetzt schon die Gegenwart und in Zukunft sind die Dinger überall drin. Mich schreckt nur der Umfang und da ich selbst noch nicht so lange damit beschäftigt bin ist das für mich als sollte ich ne Herzoperation beim Säugling durchführen und das ohne Arzt zu sein.
Ja, da habt ihr recht. Da der Cortex M4 doch ne ganze Menge zu bieten hat, wird man regelrecht erschlagen. Ich habe mir deswegen auch einfach ein paar ATMega8 und ATTiny geholt um die mit diskreten Bauelementen selbst zu beschalten. Zum Programmieren habe ich mir einen ganz einfachen AVR-USB-Programmer besorgt. Wie sieht es mit der Leistungsaufnahme von Cortex vs AVR raus. Gibt es da Vergleichstabellen?
Ingo schrieb: >>Grundsätzlich sollte man mit dem Controller ein Problem lösen, nicht >>den Controller zum Problem machen ;) Auf den Scheiterhaufen mit dir :D Wenn du den Controller zum Problem machst, hast du aber viel länger was davon ;)
Ingo schrieb: > Also ich habe mit den Tiny/Mega angefangen, über XMega zum Cortex F4. > Das Ding ist schon hart, aber auch echt cool! > > Trotzdem, fürs Hobby bleibe ich bei den Tiny/ Mega AVRs. > Sind doch etwas umgänglicher... > > Grundsätzlich sollte man mit dem Controller ein Problem lösen, nicht > den Controller zum Problem machen ;) > > > Ingo Danke Ingo! Ich schwanke sehr für die zukünftige Entwicklung. Die Cortexe haben ja auch noch Vorteile bei der Programmierung. Ist einer zu klein geworden, so kann man einfach einen größeren nehmen (soll man können; hab das so gelesen) und mit dem Programm so weiter nutzen können. Das macht die Sache wieder interessant. Der Satz, > Grundsätzlich sollte man mit dem Controller ein Problem lösen, nicht > den Controller zum Problem machen ;) ist wohl wahr und bringt es auf den Punkt. Ne Led leuchten lassen mit nem M4 ist ein bisschen auf die "Schwanzlänge" verweisen. Wenn man sich mal die ganzen Videos zum Tiny13 auf youtube anschaut, was die da alles mit machen und der kostet gerade mal 60 cent, da denke ich reicht ein 328 für viele Anwendungen.
Martin Bauer schrieb: > Wo haben die AVRs klare Vorteile zu den ARMs? Die AVRs haben (noch) Vorteile bei extrem kleinen und stromsparenden Anwendungen, der vergleichbare CortexM0+ wird aber grade verfügbar z.B. LPC8xx. Zudem gibt es für Bastler nur wenige Cortex als DIP (hier muss man dann auf DIP-Headerboards ausweichen). Vorteile Cortex: - einfacher zu programmieren für Einsteiger (Assembler und C) - bessere Codedichte (trotz 32-bit) - Bibliotheken für alles (CMSIS, USBLib, TCP/IP) - kompatibel (Code für M0 läuft auf M3 läuft auf M4) - wie schon erwähnt grosse Auswahl an (neuer) Peripherie (z.B. SPIFI, QEI) Wer das einfacher zu programmieren nicht glaubt :-) hier mal das Blinken einer LED an einem M4 am Pin 1_25 in Assembler (ok in C sind es nur 4 Zeilen): MOV R0, #1 LSL R0, R0, #25 ; R0=bit_25 ADR R1, FIO1DIR LDR R1, [R1] ; R1=&FIO1DIR STR R0, [R1] ; FIO1DIR_bit.P1_25 = 1 (output) ADR R1, FIO1PIN LDR R1, [R1] ; R1=&FIO1PIN loop LDR R2, [R1] ; read FIO1PIN EOR R2, R2, R0 ; FIO1PIN_bit.P1_25 ^= 1 (LED toggle) STR R2, [R1] ; write FIO1PIN BL delay B loop
Fürs schnelle Basteln sind die AVRs erheblich angenehmer. Man kann einfach auf ne Uniplatine einen DIP-Sockel setzen und den AVR reinstecken. Gerade beim Basteln passieren oft Unfälle (magischer Rausch entweicht) und nen TQFP-144 abzulöten, ohne daß sich Leiterzüge abheben, ist doch wesentlich umständlicher, als einen neuen AVR in den Sockel zu stecken. Auch braucht er nicht mehrere eng stabilisierte Spannungen, es reicht ihm eine Spannung irgendwo zwischen 1,8V ... 5,5V. Z.B. ne 5V USB Wandwarze oder 2 * 1,5V oder ähnliches.
Das mit der Bauform ändert sich auch gerade ein bisschen oder? Ich habe da was von einem M0 im DIL-Gehäuse gehört. Ist echt schwer als Anfänger sich da auf irgendwas erst mal einzuschießen.
Angehängte Dateien:
-
LPC1114FN28.jpg
400 KB
Peter Dannegger schrieb: > Man kann einfach auf ne Uniplatine einen DIP-Sockel setzen und den AVR > reinstecken. Stimmt, für Tests gibt es (bislang) nur einen M0 im DIP (siehe Bild). Das hat zumindest den Vorteil dass der M0 Code später auf M3 oder M4 praktisch ohne Änderungen läuft. Ansonsten sind DIP-Headerboards günstig zu bekommen z.B. http://www.embeddedartists.com/products/boards/lpc1343_qsb.php https://www.olimex.com/Products/ARM/NXP/LPC-H1343
Lothar schrieb: > hier mal das Blinken > einer LED an einem M4 am Pin 1_25 in Assembler Wow, doch so viel Code. Beim AVR (ATtiny13) sind es dagegen nur 4 Befehle. Du hast den Code für das Delay vergessen. Braucht man sonst noch irgendwelchen Startup Code?
Es wird immer schwerer gegen die Cortexe was zu sagen, jedenfalls für so Hobbyprojekte.
Lothar schrieb: > Stimmt, für Tests gibt es (bislang) nur einen M0 im DIP (siehe Bild). Gibt es den so mit Beschriftung drauf? Wenn, dann wo?
Angehängte Dateien:
-
LPC1114FN28.jpg
400 KB
Frank O. schrieb: > Gibt es den so mit Beschriftung drauf? Wenn, dann wo? Musst Du liebevoll selbst machen :-) Ist hier aber Normalpapier aus dem Tintendrucker mit Klebestift drauf gemacht (wird ja nicht heiss).
Lothar schrieb: > Frank O. schrieb: >> Gibt es den so mit Beschriftung drauf? Wenn, dann wo? > > Musst Du liebevoll selbst machen :-) Ist hier aber Normalpapier aus dem > Tintendrucker mit Klebestift drauf gemacht (wird ja nicht heiss). Wow! Auf dem Bild sieht es aus als wäre das aus Kunststoff. Sieht gut aus!
Lothar schrieb: > Peter Dannegger schrieb: >> Man kann einfach auf ne Uniplatine einen DIP-Sockel setzen und den AVR >> reinstecken. > > Stimmt, für Tests gibt es (bislang) nur einen M0 im DIP (siehe Bild). > Das hat zumindest den Vorteil dass der M0 Code später auf M3 oder M4 > praktisch ohne Änderungen läuft. > > Ansonsten sind DIP-Headerboards günstig zu bekommen z.B. Sehr günstig für reine Adapterboards (auch vom Versand her!) ist dieser hier: http://shop.anvilex.de/ Da lohnt das Runterlöten nicht mehr ;-) Chris D.
Peter Dannegger schrieb: > Wow, doch so viel Code. > Beim AVR (ATtiny13) sind es dagegen nur 4 Befehle. Auf dem 8051 auch :-) Trotzdem finde ich den ARM Assembler einfacher (und logischer). Zudem funktioniert alle Peripherie so, weil die Register von PWM, CAN usw. einfach in den 4GB Speicherraum eingeblendet sind. Alle (ausser mir) machen es auch in C :-) int main (void) { FIO1DIR_bit.P1_25 = 1; // output while(1) { FIO1PIN_bit.P1_25 ^= 1; // toggle Delay(); } return 0; } > Du hast den Code für das Delay vergessen. delay PUSH {R0} MOV R0, #1 LSL R0, R0, #18 ; 2^18=262144 (was auch immer) count SUBS R0, R0, #1 BNE count ; <>0 POP {R0} MOV R15, R14 ; PC=LR (return) > Braucht man sonst noch irgendwelchen Startup Code? Das läuft ohne Startup Code mit dem internen Oszillator (beim M4 meist 4MHz) und ohne Stromsparfunktionen. Beim externen Oszillator (100MHz oder mehr) nimmt man besser die CMSIS Funktion (PLL-Monster).
Hab gerade gesehen, dass so ein ARM Cortex M3 bei Reichelt auch gerade mal ab 3,55 EUR losgeht. Also auch vom Preis her nicht zu heftig. Zusammen mit so einer Adapterplatine auf DIL ist das auch gut zu gebrauchen auch ohne SMD gefummle. Nicht desto trotz werde ich auch mit den AVRs noch rumprobieren. Auch wenn die in Zukunft vielleicht weniger verwendet werden, so hat man sie jedenfalls mal kennengelernt. Und sie haben auch bestimmt noch ihre Daseinsberechtigung, kann ich mir jedenfalls vorstellen.
Lothar schrieb: > Peter Dannegger schrieb: >> Wow, doch so viel Code. >> Beim AVR (ATtiny13) sind es dagegen nur 4 Befehle. > > Auf dem 8051 auch :-) Trotzdem finde ich den ARM Assembler einfacher > (und logischer). Zudem funktioniert alle Peripherie so, weil die > Register von PWM, CAN usw. einfach in den 4GB Speicherraum eingeblendet > sind. Ja, das finde ich auch sehr positiv. Von "PROGMEM" etc. fange ich gar nicht erst an. Ist wohl schon zu lange her, dass ich mich darüber geärgert habe ;-) > Alle (ausser mir) machen es auch in C :-) Stimmt zumindest für mich :-) Ich hatte in den letzten 13 Jahren geschwindigkeitsmäßig noch nie so einen Flaschenhals, dass ich wirklich Assembler einsetzen musste. >> Du hast den Code für das Delay vergessen. > > delay > PUSH {R0} > MOV R0, #1 > LSL R0, R0, #18 ; 2^18=262144 (was auch immer) > count > SUBS R0, R0, #1 > BNE count ; <>0 > POP {R0} > MOV R15, R14 ; PC=LR (return) > >> Braucht man sonst noch irgendwelchen Startup Code? > > Das läuft ohne Startup Code mit dem internen Oszillator (beim M4 meist > 4MHz) und ohne Stromsparfunktionen. Beim externen Oszillator (100MHz > oder mehr) nimmt man besser die CMSIS Funktion (PLL-Monster). Unfassbar - der macht das wirklich! ;-) Chris D.
Mike schrieb: > AVR (8Bit): > + Einfach (für Einsteiger) > + freie Compiler Toolchain (AVR-GCC: Eclipse mit Plugin oder AVR-Studio) > o Peripherie/Schnitstellen > - Speed/Rechenleistung (falls das wichtig ist) Nur, weil's noch keiner erwähnt hat: + 5-V-fähig (außer Xmega) Lothar schrieb: > - kompatibel (Code für M0 läuft auf M3 läuft auf M4) Hast du innerhalb der AVR-Linie auch, interessiert aber im Zeitalter von Compilern kein Schwein.
Chris D. schrieb: > Sehr günstig für reine Adapterboards (auch vom Versand her!) ist dieser > hier: > > http://shop.anvilex.de/ > > Da lohnt das Runterlöten nicht mehr ;-) > > Chris D. Boah! Das ist günstig. In die Favoriten damit.:-) Danke Chris!
ADR R1, FIO1DIR LDR R1, [R1] STR R0, [R1] Sicher, dass das LDR da so rein gehört?
Lothar schrieb: > Trotzdem finde ich den ARM Assembler einfacher > (und logischer). Wie schafft es der ADR-Befehl, eine 32Bit-Adresse mit nur einem 32Bit-Befehl in ein Register zu schreiben. Was ist der Trick? FIO1DIR und FIO1PIN müßten doch nahebei sein. Könnte man nicht ein Displacement beim LDR angeben, anstatt die Adresse neu zu laden?
> Wo seht ihr Bereiche in denen ARMs den AVRs den Rang ablaufen könnte? Überrall. AVRs wird es bald nur noch im Museum oder als Restbestände geben.
Artjomka schrieb: > ADR R1, FIO1DIR > LDR R1, [R1] > STR R0, [R1] > > Sicher, dass das LDR da so rein gehört? FIO1DIR ist die Speicherstelle in der die Addresse vom FIO1DIR als Integer definiert ist. Man könnte die Adresse auch direkt in R1 schreiben, die ist aber 32-bit und müsste als zwei Halbwörter geladen werden. Ausserdem muss der geneigte Leser dann erst im Manual nachsehen, was diese Addresse sein soll.
Peter Dannegger schrieb: > Wie schafft es der ADR-Befehl, eine 32Bit-Adresse mit nur einem > 32Bit-Befehl in ein Register zu schreiben. Was ist der Trick? Mit ADR kann man m.W. nur Code-Adressen laden, keine I/O-Adressen. Hier angebracht wäre beispielsweise LDR R1,=FIO1DIR um die Adresse des I/O-Registers aus dem constant pool PC-relativ zu laden. In Thumb2 kann man auch 32-Bit Konstanten inline laden, benötigt dafür aber 2 32-Bit Befehle, die der Assembler aus dem Pseudobefehl MOV32 generiert. > FIO1DIR und FIO1PIN müßten doch nahebei sein. Könnte man nicht ein > Displacement beim LDR angeben, anstatt die Adresse neu zu laden? Kann man. Man läd einmal den Anfang vom I/O-Modul und arbeitet dann relativ dazu.
Lothar schrieb: > Jörg Wunsch schrieb: >> Hast du innerhalb der AVR-Linie auch > > mega <> xmega <> mega32 kompatibel ?? Was soll "mega32" dabei sein? Ein AVR32? Nein, das ist was komplett anderes, aber in jeglicher Hinsicht. Um den ging's aber in der ganzen Diskussion auch nicht (und ich würde ihn da auch nicht ins Spiel bringen). tinyAVR -> megaAVR -> Xmega sind aufwärtskompatibel, das entspricht ungefähr deiner Argumentation mit CM0 -> CM3 -> CM4. Wie schon geschrieben, interessiert das alles in der Praxis keine Sau. Bezüglich der Peripherie unterscheiden sich die ARMs verschwiedener Hersteller extrem, da ist man ohnehin nur jeweils (einigermaßen) kompatibel, solange man bei einem Hersteller bleibt. (*) In dieser Hinsicht ist dann beim AVR(8) auch ein Bruch von megaAVR nach Xmega. (*) Lediglich die systemnahen Basisblöcke sind beim Cortex-Mx nun (endlich) einigermaßen genormt, also SYSCLK, Interruptcontroller und dergleichen. Vor Cortex-M gab's auch hier riesige Unterschiede zwischen den einzelnen ARM-Herstellern.
Peter Dannegger schrieb: > Wie schafft es der ADR-Befehl, eine 32Bit-Adresse mit nur einem > 32Bit-Befehl in ein Register zu schreiben. Was ist der Trick? Gar nicht. FIO1DIR ist die Speicherstelle in der die Addresse vom FIO1DIR als Integer definiert ist. Ausserdem ist ADR kein Befehl, da macht der Assembler auch ein LDR draus. > FIO1DIR und FIO1PIN müßten doch nahebei sein. Könnte man nicht ein > Displacement beim LDR angeben, anstatt die Adresse neu zu laden? Völlig richtig! An das Displacement könnte ich mich aber in 1 Jahr nicht mehr erinnern. Ausserdem kann beim Wechsel von einem M3 auf einen M4 das Displacement auch anders sein.
Lothar schrieb: > Gar nicht. FIO1DIR ist die Speicherstelle in der die Addresse vom > FIO1DIR als Integer definiert ist. Ausserdem ist ADR kein Befehl, da > macht der Assembler auch ein LDR draus. Steht das irgendwo? Alles was ich finde besagt, dass er ein ADD oder SUB basierend auf dem PC daraus macht. Weshalb der davon abgedeckte Bereich effektiv auf den umliegenden Code beschränkt ist.
Ist es richtig, dass ich mit meinem STM32F4 Discovery Board auch anderen einzelne CortexM4 programmieren kann und gar keine extra Programminghardware brauche?
Lothar schrieb: > Völlig richtig! An das Displacement könnte ich mich aber in 1 Jahr nicht > mehr erinnern. Ausserdem kann beim Wechsel von einem M3 auf einen M4 das > Displacement auch anders sein. Lass den Assembler das ausrechnen. Sinngemäss: LDR R0, =FIO1BASE ... LDR R1, [R0, #FIO1DIR-FIO1BASE] STR R2, [R0, #FIO1PIN-FIO1BASE] Die I/O-Module sind üblicherweise <= 4K gross, so dass sie von ARM Displacements abgedeckt werden können.
Martin Bauer schrieb: > Ist es richtig, dass ich mit meinem STM32F4 Discovery Board auch anderen > einzelne CortexM4 programmieren kann und gar keine extra > Programminghardware brauche? Ja, das geht - der ST-Link ist auf den Boards eigenständig mit herausgeführten Pins. Übrigens kann man alle STM32 auch direkt über die seriellen Schnittstellen (CAN, USART, USB) programmieren. Dazu erhält jeder STM32 während der Produktion entsprechenden Code mit auf den Weg, so dass man über das entsprechende Protokoll arbeiten kann. Der Code liegt in einem geschützten Bereich und kann später nicht mehr gelöscht werden, so dass man auf jeden Fall einen STM32 reaktivieren kann (es ist also kein "Verfusen" mehr möglich). Um diesen Code zu aktivieren, gibt es die BOOT0- und BOOT1-Pins. Näheres dazu findet sich in der AN-2606 von ST: https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Attachments/18225/AN2606.pdf Das ist sicherlich später in der Produktion interessant, da eine dieser Schnittstellen wohl verwendet wird. Ansonsten reichen dann zur Programmierung drei Pins. Ich muss aber gestehen, dass ich das noch nie gemacht habe - bisher arbeiten wir mit dem Discovery-Board zum F4 und der schönen Erweiterung von wvshare.com Chris D.
Lothar schrieb: > Man könnte die Adresse auch direkt in R1 > schreiben, die ist aber 32-bit und müsste als zwei Halbwörter geladen > werden. Ausserdem muss der geneigte Leser dann erst im Manual nachsehen, > was diese Addresse sein soll. Auch das kann der Assembler selber: MOV32 R1, #FIO1BASE
NXP macht das mit den Controllern mit USB LPC11U2x und LPC11U3x und bei den Controllern LPC1342/43 so, dass man die so konfigurieren kann, dass sie sich als Massenspeicher auf dem PC melden. Datei auf den Controller draufschieben (wie bei einem Memory-Stick), Controller programmiert...
Das ist natürlich auch eine feine Sache - ob und wie sich die STM32 direkt per Massenspeicher ansprechen lassen, ist mir leider nicht bekannt.
Teensy 3.0 ist auch ein feines Cortex-Spielzeug fürs Breadboard -- und Paul ist sehr hilfsbereit. Hab mal damit einen Logikanalysator zusammengefrickelt. Hab 13MHz 8-bit Samplingrate ins RAM (16kB) erreicht! Wollte die Daten dann per DMA sammeln, RLE-enkodieren und über USB streamen. Bin dann zwar erst in einen Freescale DMA bug und dann in Probleme mit dem Streamingmodus des Open Logic Sniffer Protokolls gelaufen. Ich habs dann sein gelassen aber doch dabei wieder einiges gelernt. Das Fazit von Mike im dritten Artikel dieses Threads kann ich so auch unterschreiben. LG, Sebastian
Frank O. schrieb: > Zum Einstieg mit nem Cortex M4? Uff! Das ist aber ne harte Droge. So schlimm ist das auch nicht. Ich würde heute niemanden Raten sich nicht mit ARM zu beschäftigen. Die werden alles kanibalisieren. Ich sehe das bei uns in der Firma, da wird nix mehr anderes eingesetzt.
Lothar schrieb: > Wer das einfacher zu programmieren nicht glaubt :-) hier mal das Blinken > einer LED an einem M4 am Pin 1_25 in Assembler (ok in C sind es nur 4 > Zeilen): > > MOV R0, #1 > LSL R0, R0, #25 ; R0=bit_25 Was zum Teufel ist denn das für ein 32Bit-Prozessor, der nicht mal einen 32Bit-Wert "immediate" laden kann? Oder stellt obige Codesequenz eine Optimierung dar? Hmm. Operationen mit zwei Quellen und einem Ziel sind außerdem auch etwas gewöhnungsbedürftig. Nunja, wenn die wenigstens in jeder sinnvollen Kombination und bei jeder Operation mit zwei denkbaren Quellen möglich sind, könnte man sich daran sicher gewöhnen. Aber vermutlich trifft genau das nicht zu, wäre ja sonst zu einfach... > ADR R1, FIO1DIR > LDR R1, [R1] ; R1=&FIO1DIR Ah, ja. Scheint also doch zu geben, was ich oben vermißt habe. Allerdings bescheuertes Mnemnonik. ADR statt LD/LDI ist zumindest erkärungsbedürftig. Wahrscheinlich was ähnlich sinnvolles wie etwa "LEA", worauf nur Hochsprachenprogrammierer kommen würden, denen irgendwelches Flausen über die Besonderheiten von "pointern" im Hinterkopf rumgaukeln und die nicht begreifen, daß das letztlich auch einfach bloß Ganzzahlen sind... > STR R0, [R1] ; FIO1DIR_bit.P1_25 = 1 (output) Aha, damit wäre die Frage nach getrennten Adreßräumen für IO und Speicher auch beantwortet. Ham wa nich->memory mapped IO. Letzlich egal, muß man eben einfach nur wissen. Ingesamt: Ich habe auch schon lange darüber nachgedacht, auf ARM zwar nicht vollständig zu wechseln, aber sie zumindest zusätzlich "ins Programm aufzunehmen" für die Sachen, wo die AVR wirklich nicht mehr reichen. An den Assembler könnte ich mich sicher gewöhnen, der Befehlssatz scheint einigermaßen orthogonal zu sein. Aber es bleiben viele andere Hürden für schnelle Basteleien. Insbesondere Gehäusebauformen und Spannungsversorgung nerven. Einen AVR kaufe ich als DIL, löte ihn, eine Buchse für ISP und eine für ein 5V oder 3.3V-Standardnetzteil auf eine Streifenleiterplatte und kann dann sofort anfangen, was sinnvolles drumrum zu löten und zu programmieren. Das geht mit der ARM-Plattform alles längst nicht so einfach. Das hat mich bisher davon abgehalten, die angedachte "Programmerweiterung" auch tatsächlich zu vollziehen. Das und die Tatsache, daß es bisher kein Projekt gab, wofür ein AVR (+ggf. CPLD) wirklich nicht gereicht hätten. Es wird allerdings zunehmend eng. Über kurz oder lang werde ich wohl müssen. Es sei denn, Atmel bringt AVR mit wesentlich mehr RAM und Takt auf den Markt. Damit ist allerdings wohl kaum zu rechnen...
c-hater schrieb: > Was zum Teufel ist denn das für ein 32Bit-Prozessor, der nicht mal einen > 32Bit-Wert "immediate" laden kann? Erklär mir mal, wie ein Prozessor mit feste Befehlslänge von 32 Bits darin eine 32-Bit Konstante unterbringen soll. Soll heissen: Das hat diese Art Prozessoren so an sich. Das gilt ebenso für PowerPC, SPARC und MIPS und ein diverse verblichene. > Allerdings bescheuertes Mnemnonik. ADR statt LD/LDI ist zumindest > erkärungsbedürftig. Wenn es denn stimmen würde. > Aha, damit wäre die Frage nach getrennten Adreßräumen für IO und > Speicher auch beantwortet. Ham wa nich->memory mapped IO. Ein separater I/O-Adressraum findet sich bei 32-Bittern allenfalls aus historischen Gründen. > An den Assembler könnte ich mich sicher gewöhnen, der > Befehlssatz scheint einigermaßen orthogonal zu sein. Für gewöhnlich programmiert man die in C. Dann kanns ziemlich egal sein, wenn man nicht grad einen Compiler dafür schreibt.
c-hater schrieb: > Was zum Teufel ist denn das für ein 32Bit-Prozessor, der nicht mal einen > 32Bit-Wert "immediate" laden kann? Oder stellt obige Codesequenz eine > Optimierung dar? Ähm, beim ARM is jeder Befehl (außer im Thumb Mode) 32 bit breit, wie willsten da nen 32bit immediate reinbekommen? Nen Befehle und danach nen immediate im Flash macht das Befehldecodieren wieder komplex. c-hater schrieb: > Hmm. Operationen mit zwei Quellen und einem Ziel sind außerdem auch > etwas gewöhnungsbedürftig. Nunja, wenn die wenigstens in jeder > sinnvollen Kombination und bei jeder Operation mit zwei denkbaren > Quellen möglich sind Load and Store Architektur eben. 2 Register als Quelle, ab in die Alu und wieder zurück in ein Register. ADD R0, R0, R0 ;) Weis jetz aber auch nich was daran so gewöhnungsbedürftig is, ich würd eher an ner CPU mit accumulator ne Meise kriegen. Und jetz mal der ARM Knallerbefehl für dich ;) STMFD SP!, {R0-R12, LR} Macht nix weiter als die Register aufn Stack zu kloppen.
c-hater schrieb: > An den Assembler könnte ich mich sicher gewöhnen, der > Befehlssatz scheint einigermaßen orthogonal zu sein. Ist was für Knobler, weil man durch die ungewöhnliche Art, einen Barrel-Shifter in den Dataflow einzubauen, Dinge in einem Befehl machen kann, wofür andere 2 brauchen. Das gilt auch für die bedingte Ausführung aller Befehle.
c-hater schrieb: > An den Assembler könnte ich mich sicher gewöhnen, der > Befehlssatz scheint einigermaßen orthogonal zu sein. Wenn du einen orthogonalen Befehlssatz suchst, dann programmier' eine PDP-11. Dort waren selbst Stackpointer und PC eigentlich nur normale Register. Damit man damit einen Stack aufbauen kann oder Befehle lesen, brauchte man halt sowas wie @R7+ oder @-R6. Damit man die Vorteile derartiger Befehle auch in einer Hochsprache nutzen kann, hat C die Operatoren ++ und -- erfunden, und aus ebendiesem Grunde findest du in alten C-Quellen praktisch nur die Varianten *p++ und *--p. Die passten nämlich direkt auf die Hardware. Die Pendants *++p oder *p-- hätten deutlich mehr an Assemblercode benötigt.
> Von "PROGMEM" etc. fange ich gar nicht erst an. > Ist wohl schon zu lange her, dass ich mich darüber geärgert habe ;-) Nimm einen modernen GCC und deklariere die Variable als "__flash". Den Rest macht der Compiler für dich. Kein #include, kein pgm_read_xxx() mehr.
Jörg Wunsch schrieb: > Dort waren selbst Stackpointer und PC eigentlich nur > normale Register. Beim ARM sind Stackpointer und PC normale Register :-) R13=SP R14=LR (Rücksprungaddresse der letzten Prozedur) R15=PC
Lothar schrieb: > Jörg Wunsch schrieb: >> Dort waren selbst Stackpointer und PC eigentlich nur >> normale Register. > > Beim ARM sind Stackpointer und PC normale Register :-) Bei der PDP-11 auch, R6 und R7. Trotzdem ist der ARM nicht so extrem orthogonal wie die PDP, was natürlich auch damit zusammenhängt, dass die PDP insgesamt viel weniger konnte. Das wenige konnte sie dafür in allen möglichen Kombinationen gleichermaßen.
Lothar schrieb: > Beim ARM sind Stackpointer und PC normale Register :-) Vor ARMv3 war war sogar das Statusregister ein normales Register, nämlich ein Teil vom R15. Auch beim MSP430 sind PC, SP und Statusregister normale Register. Wie überhaupt die MSP430 ISA grosse Ähnlichkeit mit der PDP-11 hat.
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.