Hallo allerseits, ich plane in nächster Zeit auf die STM32 µC ( um genauer zu sein die F103 Serie ) umzusteigen, da das Preis/Leistungsverhältnis im Vergleich zu den AVR meiner Meinung nach deutlich besser ist. Jedoch habe ich ein paar Verständnisfragen, zu denen mir leider auch der STM32 Artikel hier nicht helfen konnte: -Worin genau liegt der Unterschied zwischen SWD und JTAG Debugging ? Beides ist doch als Debug Interface benutzbar, aber warum braucht JTAG mehr Pins ? Was bietet JTAG, was SWD nicht hat ? -Die BOOT0:1 Einstellung bestimmt ja, ob vom Flash, SRAM oder der Bootloader gestartet werden soll. Lässt sich der Bootloader auch aus einem Programm heraus starten ? Und bringt es überhaupt was, direkt vom SRAM zu booten ? Das dürfte beim Start doch voller zufälliger Werte ( oder Nullen ) sein. -Bei den F103 sind CAN und USB nicht gleichzeitig nutzbar, aber es ginge doch wenigstens abwechselnd oder ? Also nach dem Motto: wenn der Controller gerade nicht am USB hängt, nutzt er CAN. Als Programmiergerät habe ich mir übrigens den ST-Link V2 rausgesucht. Der sollte ja alle STM32er programmieren können. Den kann ich dann wenigstens direkt mit Atollic TrueStudio Lite benutzen :) Gruß, Hans
STM-Einsteiger schrieb: > -Worin genau liegt der Unterschied zwischen SWD und JTAG Debugging ? JTAG dürfte schneller sein und ist vom Protokoll her standardisiert. SWD ist eher proprietär. > Und bringt es überhaupt was, direkt vom SRAM zu booten ? Das dürfte beim > Start doch voller zufälliger Werte ( oder Nullen ) sein. Du könntest deine Applikation per Debugger in den Speicher bringen. Das dürfte zum Testen schneller sein und auch den Flash schonen. > -Bei den F103 sind CAN und USB nicht gleichzeitig nutzbar, aber es ginge > doch wenigstens abwechselnd oder ? Also nach dem Motto: wenn der > Controller gerade nicht am USB hängt, nutzt er CAN. Wenn Du bei Protokolle in deinem Programm unterstüzt (und das dann noch in den Flash passt) sollte das gehen. Grüße Sven
STM-Einsteiger schrieb: > -Bei den F103 sind CAN und USB nicht gleichzeitig nutzbar, aber es ginge > doch wenigstens abwechselnd oder ? Alternativbetrieb geht. Nur beides nicht gleichzeitig. Grund ist der gemeinsame Bufferspeicher von 512 Byte. Es gibt größeres STM32 Typen die CAN und USB gleichzeitug können. Sven Wagner schrieb: > Du könntest deine Applikation per Debugger in den Speicher bringen. Das > dürfte zum Testen schneller sein und auch den Flash schonen. Das mache ich auch manchmal. Geht natürlich nur bei kleinen Programmen. Mit dem Atollic TrueStudio Lite leider nicht ganz einfach zu machen, da man schon bei der Projektanlage FLASH oder SRAM als Ziel auswählen muss.
Ein neues Projekt würde ich mittlerweile nicht mehr mit den 103ern anfangen - es gibt eigentlich nur noch einen Grund, für diese Serie, nämlich wenn man LQFP48 benötigt (und ggf. der Preis). Ansonsten haben wir seit ein paar Monaten die F2xx im Einsatz und kann bisher nur gutes berichten. Kleinstes Gehäuse ist hier allerdings LQFP64. Eine alternative wäre noch der F105, der ebenfalls USB und CAN gleichzeitig kann.
Danke für die Infos, es spielt also an sich keine Rolle ob ich JTAG oder SWD benutze ( außer dass ich bei SWD weniger Pins verschwende ). Hannes S. schrieb: > Ein neues Projekt würde ich mittlerweile nicht mehr mit den 103ern > anfangen - es gibt eigentlich nur noch einen Grund, für diese Serie, > nämlich wenn man LQFP48 benötigt (und ggf. der Preis). Ansonsten haben > wir seit ein paar Monaten die F2xx im Einsatz und kann bisher nur gutes > berichten. Kleinstes Gehäuse ist hier allerdings LQFP64. Es geht hier immer noch um Hobbyeinsatz, wurde wohl noch nicht so klar. Und die F2xx sind noch schwerer zu bekommen als die F1xx Reihe ... selbst Farnell hat sie nicht.
STM-Einsteiger schrieb: > -Worin genau liegt der Unterschied zwischen SWD und JTAG Debugging ? Das Motiv für SWD ist die Anzahl dafür erforderlicher Leitungen. > warum braucht JTAG mehr Pins ? Im diesem Kontext: Weil JTAG ein paar Jahrzehnte früher erfunden wurde.
STM-Einsteiger schrieb: > ich plane in nächster Zeit auf die STM32 µC ( um genauer zu sein die > F103 Serie ) umzusteigen, da das Preis/Leistungsverhältnis im Vergleich > zu den AVR meiner Meinung nach deutlich besser ist. Also mir ist der Preis des MC schnurzpiepegal. Ist ja in der Regel unter 20€. Die Entscheidung, welcher MC, treffe ich ausschließlich, ob er die Aufgabe lösen kann und dann nach der kürzesten Entwicklungszeit (Schaltung + Layout + Software). Den Cortex M3 habe ich mir auch schon angesehen. Mir fehlt bloß noch die ultimative Poweraufgabe, damit ich ihn auch sinnvoll einsetzen kann. Peter
Peter Dannegger schrieb: > Also mir ist der Preis des MC schnurzpiepegal. Ist ja in der Regel unter > 20€. O HA! Das klingt ja wie Krösus persönlich! Ich vermute aber mal, daß das Geld, was du so freizügig ausgibst, eigentlich das Geld deines Chefs ist.. Ich für meinen Teil sehe schon ganz früh beim Definieren der Aufgabe auf den zu erwartenden Preis, weil es sich sonst inder Serie irgendwann nicht mehr rechnet. Also unser STM-Einsteiger hat ja wohl ganz klar geschrieben "Es geht hier immer noch um Hobbyeinsatz". Naja, das heißt, daß er nicht mit Geld um sich schmeißen kann und/oder will und daß er sein Zeugs dort einkaufen muß, wo man als Privater kaufen kann. Ich würde ihm schlicht und einfach dazu raten, den eingebauten Bootlader zu benutzen. Zum Kommunizieren mit dem uC braucht er die serielle Schnittstelle sowieso, also ist sie auch gut genug für's Brennen der Firmware. (Gilt übrigens auch für die uC's von NXP) Ansonsten kann ich ganz pauschal die Cortexe nur wärmstens empfehlen, weil sie ENDLICH!! das fertig bringen, was ne x86 CPU schon ewig kann: Zugreifen auf krumme Adressen. Dadurch hat man es mit Records/Struct's leichter, ebenso mit Zeigern auf Word und DWord. Sowas empfinde ich als echte Erleichterung. Die ganze Debuggerei inclusive JTAG/SWD hingegen ist eigentlich zweitrangig, wenn man es erstmal geschafft hat, eine Kommunikation über V24 hinzubekommen. W.S.
> Also unser STM-Einsteiger hat ja wohl ganz klar geschrieben "Es geht > hier immer noch um Hobbyeinsatz". Naja, das heißt, daß er nicht mit Geld > um sich schmeißen kann und/oder will und daß er sein Zeugs dort > einkaufen muß, wo man als Privater kaufen kann. Nun, wenn Peter schreibt, dass der MC die "Aufgabe lösen können muss", dann landet er in der Regel bei einem kleinen attiny, welcher preislich weit unter 20 EUR liegt :-) > Ich würde ihm schlicht und einfach dazu raten, den eingebauten Bootlader > zu benutzen. Zum Kommunizieren mit dem uC braucht er die serielle > Schnittstelle sowieso, also ist sie auch gut genug für's Brennen der > Firmware. (Gilt übrigens auch für die uC's von NXP) Ein guter Kandidat ist dafür das LPCXpresso mit einem lpc1769 für gute 20 EUR. Der hat CAN, Ethernet und USB. Das Ding ist sein Geld wert. > Die ganze Debuggerei inclusive JTAG/SWD hingegen > ist eigentlich zweitrangig, wenn man es erstmal geschafft hat, eine > Kommunikation über V24 hinzubekommen. So ist es.
W.S. schrieb: > O HA! Das klingt ja wie Krösus persönlich! Ich vermute aber mal, daß das > Geld, was du so freizügig ausgibst, eigentlich das Geld deines Chefs > ist.. Der zahlt ihm aber auch das Gehalt und das Entwicklungssystem. Ich schätze dass seine Projekte keine 100000er Stückzahlen erreichen, sondern weit weit darunter liegen. In einem Bereich, in dem die Entwicklungskosten einen grösseren Anteil haben als die Kosten des Controllers. Folglich ist der Einsatz bekannter Hardware ohne Einarbeitungszeit selbst dann lukrativer, wenn der Controller 10€ mehr kosten sollte.
> Den Cortex M3 habe ich mir auch schon angesehen. Mir fehlt bloß noch die > ultimative Poweraufgabe, damit ich ihn auch sinnvoll einsetzen kann. Zumal der GCC mit -Os bei meinen Programmen oft genug für den Cortex-M3 kleinere Programme erzeugt. Da kriegt man kaum die "Kleinen" mit 128kb voll. Auch ohne Poweraufgabe finde ich es gut, wenn es genügend Timer gibt. Das erleichtert schon das SW-Design. Auch schön, wenn es einfach immer genügend Schnittstellen gibt. Kein GCC PROGMEM Gebastel, integrierter "boot loader", zumindest im Falle des STM32 einen "fractional baud rate generator", alle Timer haben min. 16-Bit, frei einstellbare Prescaler, Hardware exception handler usw.
Nochmal wegen der JTAG-Schnittstelle. Mir war der 20-Polige Standard-Stecker immer zu globig, außerdem sind die Pins schlecht angeordnet. Wenn Du Boards selbst machst, dann empfehle ich mal den Stecker/Pinbelegung an zu schauen: http://www.mikrocontroller.net/articles/JTAG#Der_10-polige_JTAG_Stecker_von_mmvisual Es braucht nur eine kleine Adapter-Platine, nur schade, dass die meisten JTAG-Interfaces nicht gleich ein COM-Port mit dabei haben. PS: Schaue Dir auch mal CooCox.org an.
W.S. schrieb: > Zugreifen auf krumme Adressen. Dadurch hat man es mit Records/Struct's > leichter, ebenso mit Zeigern auf Word und DWord. Sowas empfinde ich als > echte Erleichterung. Wobei dir hier offenbar schnurzegal ist, dass die Performance dann darunter leidet, weil der Speicher eben doch in epischer Wortbreite angebunden ist. Aber klar: wenn der eine uC zu langsam ist, dann nimmt man eben den schnelleren... :-/
W.S. schrieb: > Ansonsten kann ich ganz pauschal die Cortexe nur wärmstens empfehlen, > weil sie ENDLICH!! das fertig bringen, was ne x86 CPU schon ewig kann: > Zugreifen auf krumme Adressen. Dann pass aber auf, dass dir nie ein Cortex M0 unterkommt.
>JTAG dürfte schneller sein und ist vom Protokoll her standardisiert. Bei JTAG sind nur die Anschlüsse standardisiert, aber nicht das Protokoll. JTAG von einer uC-Architektur wird nicht auf eine andere Architektur passen. >..weil sie ENDLICH!! das fertig bringen, was ne x86 CPU schon ewig kann: >Zugreifen auf krumme Adressen. Dadurch hat man es mit Records/Struct's >leichter, ebenso mit Zeigern auf Word und DWord. Das ist eigentlich Standard und das können viele andere uCs (<>X86) schon lange. Und wenn sogar der Preis ..20 eu schnurzpiepegal ist, wäre das ja ein Grund eine möglichst leistungsfähige Architektur zu nehmen. Aber das ist nicht ARM-CM3, insbes. weil 1.) es RISC-Architekt ist (braucht von Hause aus schon mehr Befehle als CISC, müsste also entspr. höher getaktet sein), und 2.) statt einer nötigen höheren Progr-Speicher-Frequenz ist diese Frequenz auch noch deutlich geringer!. Also kommen da gleich 2 Nachteile zusammen! Asserdem hat ARM-CM3 weder DSP-Funktionen noch FloatingPoint.
W.S. schrieb: > Ich für meinen Teil sehe schon ganz früh beim Definieren der Aufgabe auf > den zu erwartenden Preis, weil es sich sonst inder Serie irgendwann > nicht mehr rechnet. Das mache ich doch auch. Und deshalb lasse ich solche winzigen Posten, die unter 1% der Materialkosten liegen, erstmal unberücksichtigt und betrachte nur die wirklich großen Brocken, z.B. Entwicklungszeit. Die gesparte Zeit zählt ja mehrfach, nicht nur weniger Arbeitszeit, sondern auch früher am Markt. Peter
W.S. schrieb: > weil sie ENDLICH!! das fertig bringen, was ne x86 CPU schon ewig kann: > Zugreifen auf krumme Adressen. Das ist ja erfreulich. Oft hat man Protokolle mit 1-, 2-, 4-Byte Daten und Arrays gemischt und die möchte man ja ohne Klimmzüge aus dem Puffer lesen können. Sehr schön wäre es, wenn man dann noch beliebige Byte-Order einlesen könnte. Der ARM7-TDMI kann das wohl noch nicht. Mein Kollege hatte jedenfalls mächtig geflucht, als er eine Protokollschicht vom 8051 auf den ARM portieren mußte. Peter
Peter Dannegger schrieb: > Der ARM7-TDMI kann das wohl noch nicht. Er kann zwar byteweise auch auf ungerade Adressen zugreifen, aber er kann nicht ein Wort (16Bit) oder gar ein D-Wort (32Bit) an einer ungeraden Adresse beginnen lassen...
Peter Dannegger schrieb: > Sehr schön wäre es, wenn man dann noch beliebige Byte-Order einlesen > könnte. Wer diesen Schnick-Schnack braucht, wäre mit Renesas RX610 oder RX62N gut bedient. Die schaufeln die Werte um, wie es einem gerade gefällt. Die Reihenfolge (little/big endian) läßt sich dabei auch noch einstellen. Sofern ein ExDMA-Controller vorhanden ist, kann man auch beispielsweise einen long-int in Bytes aufsplitten und diese mit wählbaren Offset im ext. Speicher ablegen, wenn ich nicht irre. 32-bit float gibt's auch und vieles, vieles mehr mit 100MHz ohne Wartezyklen. Obwohl diese Teile mit 2MB-Flash/128KB-RAM unter €20 kosten, passen sie wohl nicht so recht in ein Forum für ARMe :-) Wider Erwarten gibt es sie schon wieder aus Japan: http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=R5F56108VNFP%23V0-ND
Was habt ihr ständig mit den 20 EUR???? Siehe hier: http://www.tme.eu/de/katalog/index.phtml#cleanParameters%3D1%26searchClick%3D1%26search%3DSTM32F103%26bf_szukaj%3D+ Der gute mit 512K Flash kostet grad mal 12,50.
> Der gute mit 512K Flash kostet grad mal 12,50. Für das Geld gibt es schon den STM32F2-nochwas mit 1MB. Aber das war doch nur ein Beispiel dafür das man die Kosten fürs Silizium nicht überbewerten sollte. Ich hätte mir ja schon längst mal ein Evalboard mit einem RX besorgt. Zero-waitstate ist mir egal (wird auch überbewertet) aber DSP/FPU Instruktionen kann ich gebrauchen. Doch ohne I2S Schnittstelle nutzt mir das nichts. Der FPU fehlt auch die MAC-Einheit. Und dann auch nur 16Bit Timer auf einem 32Bit Controller... Hab ich schon beim STM32F1 nicht verstanden was das soll. Die laufen doch permanent über. Die großen RX600 mit den "LCD-Controllern" unterstützen nur 16bpp. Anscheinend kann auch der externe Speicher nur 16Bit breit sein. Noch vor zehn Jahren konnte man jemanden ein 16Bit Display zeigen. Heute wird man dafür bemitleidet. Das geht einfach nicht. Selbst der LPC2478 mit seinem 72MHz ARM7 Kern kann 24bpp. Ist sogar ziemlich fix bei QVGA Auflösung. Mit 32Bit SD-RAM auch bei 480x272. Traut man dem Kerl gar nicht zu ;). Naja, vielleicht mal ein RX200 zum Spielen. Wenn es oben klemmt, klappt es vielleicht unten. Da wird neu gewürfelt. Aber es zeigt sich immer wieder das letztlich das Gesamtpaket stimmen muss. Einzelne herausragende Merkmale reichen nicht. MCUA schrieb: > Asserdem hat ARM-CM3 weder DSP-Funktionen noch FloatingPoint. Nicht ganz: Multiply-Accumulate- und Saturation Befehle sind vorhanden. Damit lässt sich schon etwas anfangen. Floating Point kann er freilich nicht. Und nochmal zum Thema: STM-Einsteiger schrieb: > -Worin genau liegt der Unterschied zwischen SWD und JTAG Debugging ? JTAG ist viel älter als SWD und erlaubt im Prinzip das Kaskadieren mehrerer Bausteine (macht das heute noch wer?). Das kann SWD soweit ich weiß nicht. Beide Schnittstellen arbeiten seriell. Von der Geschwindigkeit her ist mir beim J-Link bislang kein Unterschied aufgefallen. Allerdings benutze ich das Teil selten. In diesem Jahr bisher noch gar nicht. Ich müsste es auch erst suchen ;). SWD wird von weniger Geräten unterstützt. Die preiswerten und zum Teil als Bausatz angebotenen Debugger können im Zweifelsfall nur JTAG.
Michael G. schrieb: > Die großen > RX600 mit den "LCD-Controllern" unterstützen nur 16bpp. Anscheinend kann > auch der externe Speicher nur 16Bit breit sein. Du hattest gestern wohl einen schlechten Tag und konntest nicht einschlafen? Anders kann ich mir Deine fiktiven hochgeschraubten Anforderungen nicht erklären. Ein Blick ins Datenblatt hätte gereicht: die RX600-Serie hat garkeinen LCD-Controller. Man kann aber per ExDMA ein TFT betreiben - auch mit 32bpp. Zurück zum STM32: auch mit 16Bit-Timern kann man leben. Wenn es 32Bit-Timer gäbe, käme irgendein Schnulli und würde schipmpfen, weil er 64Bit braucht. Ich würde STM-Einsteiger empfehlen, einzusteigen und loszufahren. Wie bei jeder Fahrt kann sich auch die Richtung ändern; nur Sackgassen sollte man meiden :-)
>zero-waitstate ist mir egal (wird auch überbewertet) Das sagen, die, die grottenschlechten Flash haben. (Da werden aus 120 MHz schnell mal 30 MHz!) >Doch ohne I2S Schnittstelle nutzt mir das nichts. Auch das geht >Und dann auch nur 16Bit Timer auf einem 32Bit Controller... Hab ich schon >beim STM32F1 nicht verstanden was das soll. Die laufen doch permanent >über. Unsinn. Was haben 32bit Register mit 32bit Timern zu tun? Läuft da die Zeit 64k x schneller? >die großen RX600 mit den "LCD-Controllern" unterstützen nur 16bpp. Unsinn (wurde schon erläutert). >Selbst der LPC2478 mit seinem 72MHz ARM7 Kern Und mit Flash 30 MHz? >Anscheinend kann auch der externe Speicher nur 16Bit breit sein. Falsch. Manche RX-ICs unterstützen auch 32 Bit breite. >Nicht ganz: Multiply-Accumulate- und Saturation Befehle sind vorhanden. Selbst (nur) die nur über LD/ST. Das dauert. >Die preiswerten und zum Teil als Bausatz angebotenen Debugger können im >Zweifelsfall nur JTAG. Aber nicht wenn der uC nur SWD unterstützt.
>Du hattest gestern wohl einen schlechten Tag und konntest nicht einschlafen? Nicht schlecht aber lang ;). >>zero-waitstate ist mir egal (wird auch überbewertet) > Das sagen, die, die grottenschlechten Flash haben. (Da werden aus 120 > MHz schnell mal 30 MHz!) Bei NXP sind es oft sogar nur 20MHz. Aber wann ist das relevant? Solange man keine harten Echtzeitbedingungen hat zählt nur die durchschnittliche Ausführungszeit. Und da zeigen die Cache Architekturen schon Wirkung. Zur DSP-Lib von NXP sind Takte angegeben. Z. B. für eine 256 Punkt FFT: 20MHz: 21107 120MHz: 23884 (Werte für LPC1769) Ich nehme an das dir das zu schlecht ist, mir genügt das aber. Beim STM32F1xx ist die Abhängigkeit vom Takt etwas größer, habe die Daten gerade aber nicht zur Hand. Beim STM32F2xx sollen die Werte etwa denen von NXP entsprechen. Zahlen habe ich dazu allerdings noch nicht gesehen. Die Werte decken sich auch mit meinen Versuchen bei 12MHz. Der Einfluss der Waitstates war erstaunlich gering. Auch bei kurzen Schleifen. Bei letzteren bricht die Performance beinahe unabhängig von Waitstates ein, was ich auf die Pipeline zurückführe. >>Doch ohne I2S Schnittstelle nutzt mir das nichts. > Auch das geht Du beziehst dich jetzt aber hoffentlich nicht auf die Lösung mit der SPI Schnittstelle? >>Und dann auch nur 16Bit Timer auf einem 32Bit Controller... Hab ich schon >>beim STM32F1 nicht verstanden was das soll. Die laufen doch permanent >>über. > Unsinn. Was haben 32bit Register mit 32bit Timern zu tun? Läuft da die > Zeit 64k x schneller? 16Bit Timer laufen nunmal schnell über, egal auf welchem Controller. Bei 32Bit kann man mit 1µs Auflösung arbeiten und hat erst nach über einer Stunde einen Überlauf. 32Bit Controllern ist es egal ob sie auf 16- oder 32Bit Register zugreifen. 32Bit Timer führen hier also zu keinem Mehraufwand. Das ein Hersteller sich dennoch auf 16Bit beschränkt wundert mich. Ein- oder zwei 32Bit Timer reichen schon. Der Rest für PWM usw. kann ja 16-bittig sein wenn sich dadurch Silizium sparen lässt. >>die großen RX600 mit den "LCD-Controllern" unterstützen nur 16bpp. > Unsinn (wurde schon erläutert). Gut, alles andere ergibt heutzutage zumindest im Konsumerbereich keinen Sinn. Ich habe die Angabe von Renesas zu ihrem "Direct LCD" oder wie die das nennen zu ernst genommen. Da ist nämlich von 16bpp die Rede. Oder gibt es zwei Varianten? >>Selbst der LPC2478 mit seinem 72MHz ARM7 Kern > Und mit Flash 30 MHz? Mit 20MHz, ja. >>Anscheinend kann auch der externe Speicher nur 16Bit breit sein. > Falsch. Manche RX-ICs unterstützen auch 32 Bit breite. Auch gut, s. o. >>Nicht ganz: Multiply-Accumulate- und Saturation Befehle sind vorhanden. > Selbst (nur) die nur über LD/ST. Das dauert. Irgendwie glaube ich nicht das sich der alte Streit zwischen den CISC - RISC/load-store Fraktionen in einem Forum beilegen lässt. Ich habe Professoren erlebt die sich deswegen angeschrien haben. >>Die preiswerten und zum Teil als Bausatz angebotenen Debugger können im >>Zweifelsfall nur JTAG. > Aber nicht wenn der uC nur SWD unterstützt. Doch, auch dann. An einem µC ohne JTAG funktionieren die nur nicht ;) Markus Müller schrieb: > Manche STM32 Derivate (SMT32F20x) haben auch 32 Bit Timer. Ende gut, alles gut ;). ST dürfte damit nach Luminary und NXP der dritte (ARM-) µC Hersteller sein der das macht.
>Ende gut, alles gut ;) Auch wenn man sich erst für einen STM32F103 entscheidet und später man zu einem STM32F20x umsteigen möchte, die Dinger sind nehezu PINKOMPATIEBEL! Somit ist ein STM32, auch wenn man erst mal mit einem kleineren anfängt, keine Einbahnstraße, bzw braucht nur die zwei Pins umverdrahten und kein Komplett-Redesign.
Michael G. schrieb: > Zur DSP-Lib von NXP sind Takte angegeben. Z. B. für eine 256 Punkt FFT: > 20MHz: 21107 > 120MHz: 23884 > (Werte für LPC1769) Ein provokanter Vergleich: Auf einen Blick kann man sehen, dass bei 20MHz die schnellste Berechnung erfolgt, warum dann mit 120MHz takten? :-) Bei näherem Hinsehen sieht man einen Leistungseinbruck von immerhin 11,6%; das ist doch nicht wenig? Auf den 3. Blick kann man vermuten, dass die übrige Architektur des LPC so schlecht ist, dass noch viel Zeit woanders vertrödelt wird :-) Im Ernst: solange sich die Wunschroutine im Cache befindet, ist ja alles ganz toll. Wenn aber ein Interrupt einschlägt, und den Cache zerschießt, muß immer brav nachgeladen werden.
>>> Selbst der LPC2478 mit seinem 72MHz ARM7 Kern >> Und mit Flash 30 MHz? > Mit 20MHz, ja. Was hier für ein Schwachsinn geschrieben wird ! Wohl noch niemand was von einem Memory Accelerator Modul gehört ? Aus dem Flash wird zwar mit 20 MHz gelesen und bei 60 MHz alle 3 Takte der Befehl ausgeführt, nur innerhalb der zwei Takte dazwischen werden weitere 2 Instruktionen geladen, sodass eine kontinuierliche Befehlsausführung fast im CPU Takt erfolgt, nur etwas Zeitversetzt. Hab hier ein 800x480 16bit TFT an LPC2478 dranhängen und der Geschwindigkeitsunterschied bei Befehlsausführung zwischen int. SRAM und Flash mit dem MAM ist sehr gering. Ohne MAM ist das Ganze mit dem Flash fast dreimal so langsam.
Peter Dannegger schrieb: > Der ARM7-TDMI kann das wohl noch nicht. Eigentlich können so ziemlich ALLE älteren Risc-Architekturen nicht wirklich auf "krumme" Adressen zugreifen, also ARM, MIPS, FR und so weiter. Dazu kommt bei einigen noch das Gehampel mit der Byteordnung (big/little endian). Ich hab das durch mit Quellen, die sowohl für ARM als auch für Fujitsu FR geeignet sein sollen. Naja, ARM scheint mit den Cortexen auf dem Wege der Besserung zu sein, also endlich ein effektiverer Code als bislang, Verbesserung bei den Interrupts, 'unalignete' Zugriffe. Jetzt fehlt nur noch der Befehlscache (wie bei den Fujitsu-FR). BTW: Ist eigentlich wieder mal ein bissel traurig: Die FR waren vor langen Jahren schon besser, schöner und schneller als ARM und Konsorten, die Tools gibt's kostenlos und trotzdem fristen sie ein Dasein als Mauerblümchen, während Fujitsu auf Cortex umsteigt. Naja, so ist das Leben. Und nochwas zu den zwischenzeitlichen Einwürfen wegen der Performance: Mir ist es 1000x lieber, der uC macht beim Laden eines 'unaligneten' DWORD's mal 2 oder 3 Zugriffe, als daß er Müll ins Register lädt mit anschließender Fehlfunktion - und die Alternative L = (a<<24)||(b<<16)||(c<<8)||d ist auch alles andere als angenehm. W.S.
W.S. schrieb: > Naja, ARM scheint mit den Cortexen auf dem Wege der Besserung zu sein, > also endlich ein effektiverer Code als bislang, Verbesserung bei den > Interrupts, 'unalignete' Zugriffe. Jetzt fehlt nur noch der Befehlscache Alles eine Frage des Aufwands. Die Funktionalität ist probemlos realisierbar, an Unfähigkeit seitens ARM liegt es nicht. Vielmehr wird die Komplexität von Cores bewusst auf einen angenommenen Zielmarkt ausgerichtet, und Caches gehörten bei der Cortex M Reihe nicht dazu. Sie hätten den Core beträchtlich aufgeblasen und so teurer gestaltet. An der Fähigkeit zu unaligned Accesses sieht man das ja auch. In den M3 ist das drin, wohl weils in diesem Zielmarks sinnvoll erschien. In der minimalisierten Variatanten wie M0 und M1 hingegen fehlt diese Fähigkeit hingegen, eben um deren Cores zu vereinfachen. Nicht selten ist es bei eingekauften Cores auch so, auch bei diversen ARMs in der Vergangenheit, dass sie als Baukasten verkauft werden. In denen Caches als Option auftreten, die der Kunde verwenden kann oder auch nicht. Sei es weil er modular konstruiert ist, sei es weil man den Core in beiden Varianten anbietet. Dann liegt es nicht in der Verantwortung von ARM, ob in einem Controller ein Cache verwendet wird, sondern beim Kunden.
> 32Bit Controllern ist es egal ob sie auf 16- oder 32Bit Register > zugreifen. 32Bit Timer führen hier also zu keinem Mehraufwand. Aber ein 32bitTimer es viel mehr Silicium-Aufwand, und meistens braucht man den einfach nicht. (PWM-Auflösung mit 32Bit braucht man auch nicht) >>>Nicht ganz: Multiply-Accumulate- und Saturation Befehle sind vorhanden. >> Selbst (nur) die nur über LD/ST. Das dauert. >Irgendwie glaube ich nicht das sich der alte Streit zwischen den CISC - >RISC/load-store Fraktionen in einem Forum beilegen lässt. Der Streit lässt sich vielleicht nicht beilegen, aber bei geringer Opcode-Speicher-Frequenz hat RISC verloren. >>>> Selbst der LPC2478 mit seinem 72MHz ARM7 Kern >>> Und mit Flash 30 MHz? >> Mit 20MHz, ja. >Was hier für ein Schwachsinn geschrieben wird ! >Wohl noch niemand was von einem Memory Accelerator Modul gehört ? Den Schwachsinn lass ich bei dir. (Bist wohl zu sehr auf ST reingefallen) Dieser Memory Accelerator (ist nur Art Cache) funkt. nur dann (schon in vorigen Threads erläutert), wenn -nachdem dieser Cache angesprungen, und nach 4 Befehlen- danach die Befehlsfolge lin. ansteigend ist (weil dann wieder aus dem lahmen Flash gelesen werden muss). Somit versagt das Ding, danach mehrere unlineare Befehle folgen. Es würde NUR DANN NICHT versagen, wenn jede Opcode-Speicherstelle in diesem Cache liegen würde, was aber heissen würde, dass faktisch der ganze Speicherbereich aus SRAM bestehen würde, was viel zu teuer wäre. (Und unlineare Befehle sind alles andere als selten) >Im Ernst: solange sich die Wunschroutine im Cache befindet, ist ja alles >ganz toll. Wenn aber ein Interrupt einschlägt, und den Cache zerschießt, >muß immer brav nachgeladen werden. Da hält der o.b. "Memory Accelerator" die ersten 4 Befehle bereit, danach muss wieder ausm Flash gelesen werden. Pech, wenn danach schon wieder unlineare Befehle folgen.
MCUA schrieb: > Dieser Memory Accelerator (ist nur Art Cache) Yep, so sind Caches eben. Sie nutzen die Statistik. Wenns in 90% der Fälle was nützt, dann hat man unter dem Strich mit relativ überschaubarem Aufwand eine beträchtliche Performance-Steigerung - statistisch. Dass manche Anwendungen aufgrund ihrer Charakteristik mit Caching und anderen Massnahmen zur hoffnungsvollen Steigerung der Performance nicht zurecht kommen liegt auf der Hand. Wie bei der Statstik auch, manche fallen eben aus dem statistischen Erwartungsbereich heraus. Das ist bei PC-Prozessoren nicht anders. Intels Netburst-Architektur (Pentium 4) war ein drastischen Beispiel dafür, weil man auf recht einfache und in alten Programmen nicht selten zu findende Weise einen solchen High-End Prozessor regelrecht zur Schnecke machen konnte. Man kann als Anwender also davon profitieren - was insgesamt wahrscheinlich ist - oder man kann zu jenen gehören, bei denen das nicht funktioniert. Man kann dann versuchen, die Hardware dem Programm anzupassen, oder das Programm an die Hardware. Ein Anbieter von Controllern kann daraus natürlich die Konsequenz ziehen, und auf Caches und solche als Accelleratoren getarnte Caches komplett verzichten. Wenn oder vielleicht weil man in der Lage ist, den Speicher auch ohne sie entsprechend schnell zu halten. Offenbar hat das aber gewisse mindestens für den Hersteller unangenehme Nebenwirkungen, weshalb diese Methode bei Controllern im Bereich um die 100MHz (+/-50) nicht universell verbreitet ist.
A. K. schrieb: > Ein Anbieter von Controllern kann daraus natürlich die Konsequenz > ziehen, und auf Caches und solche als Accelleratoren getarnte Caches > komplett verzichten. Naja, also nach allem, was ich in den letzten Jahren so gesehen habe, ist es wohl unsäglich schwierig, einen Flashrom wesentlich schneller als ca. 50 ns Zugriffszeit zu machen. Da helfen eben nur 3 Strategien: 1. Booten, d.h. alles vom Flash in einen hinreichend großen RAM zu verfrachten 2. schmaler Code und breiter Zugriff, z.B. 16 bit breiter Maschinencode und Zugriff auf den Flash mit 128 bit (wo dann gleich mehrere Befehle geladen werden) 3. Befehlscache, um den Flash zu entlasten. Bei NXP (so aus dem Stegreif) 16 bit Code (thumb) und 128 bit Flashzugriff. Und bei ST ? Hab ich da trotz Alz.. schlichtweg 2 Waitstates ab ca. 38 MHz Takt in Erinnerung?? (bin i.M. zu faul, das unübersichtliche RefMan herauszusuchen..) W.S.
W.S. schrieb: > Naja, also nach allem, was ich in den letzten Jahren so gesehen habe, > ist es wohl unsäglich schwierig, einen Flashrom wesentlich schneller als > ca. 50 ns Zugriffszeit zu machen. Da helfen eben nur 3 Strategien: Ungesagter Hintergrund von MCUAs Argumentation ist eine von Renesas bei einigen Modellen beworbene Flash-Technik mit einem Takt Zugriffszeit bei 100MHz. So steht es da jedenfalls, auf Details wird leider verzichtet. > 2. schmaler Code und breiter Zugriff, z.B. 16 bit breiter Maschinencode > und Zugriff auf den Flash mit 128 bit (wo dann gleich mehrere Befehle > geladen werden) Das ändert aber nichts an der Zugriffszeit, nur die Transferrate gewinnt dabei. Diese Methode hat bereits NXP mit den LPC2000 verwendet um auch mit 32-Bit Code noch zurecht zu kommen. > Und bei ST ? Hab ich da trotz Alz.. schlichtweg 2 Waitstates ab ca. 38 > MHz Takt in Erinnerung?? (bin i.M. zu faul, das unübersichtliche RefMan > herauszusuchen..) STM32, nehme ich an. Passt. Bei den 100er Modellen ist die Transferrate grad so eben ausreichend, um bei den Waitstates von 72MHz sequentiell einen moderat gemischten 16/32-Bit Code ohne grössere Einbussen ausführen zu können. Nichtsequentiell hat man die Waitstates an der Backe, erst die 200er haben einen Cache fürs Flash, der dann auch bei nichtsequentellen Zugriffen hilft. Man sollte übrigens auch die Datenzugriffe nicht vergessen. Anders als bei den CM3 kommt man bei den klassischen ARMs (und bei Thumb-1) oft nicht um PC-relative Zugriffe herum, d.h. Datenzugriffe ins Flash. Ohne Cache siehts dann ganz bös aus und insbesondere der STR9 hat damit ein ziemliches Problem. Bei dessen ziemlich vielen Waitstates ist jeder solche Zugriff eine mittlere Katastrophe.
A. K. schrieb: > So steht es da jedenfalls, auf Details wird leider verzichtet. Monos-flash ist das Stichwort: http://www.renesas.eu/products/mpumcu/flash/child_folder/monos_child.jsp A. K. schrieb: > Offenbar hat das > aber gewisse mindestens für den Hersteller unangenehme Nebenwirkungen, > weshalb diese Methode bei Controllern im Bereich um die 100MHz (+/-50) > nicht universell verbreitet ist. Ich denke, für die Mitbewerber hat es unangenehme Nebenwirkungen, weil die Technik wohl patentiert ist. Dann muß man auch sagen, dass Renesas in diesen Segmenten kein Billigheimer ist; aber die Leistung stimmt und ist ihr Geld wert.
Willi schrieb: > Dann muß man auch sagen, dass Renesas in diesen Segmenten kein > Billigheimer ist; aber die Leistung stimmt und ist ihr Geld wert. Yep. Wahrscheinlich kriegt man damit keine <5€ LPC1000 oder STM32 zustande, kann damit nicht gegen die 8/16-Bit Controller-Riege anstinken, was ja die Intention hinter diversen Controllern auf Basis von Cortex-M3 und -M0 ist. So hat eben jeder seinen Markt.
> Dann muß man auch sagen, dass Renesas in diesen Segmenten kein > Billigheimer ist; aber die Leistung stimmt und ist ihr Geld wert. .... >Yep. Wahrscheinlich kriegt man damit keine <5€ LPC1000 oder STM32 >zustande, Von wegen. Renesas uC's kosten ab ca 1eu. (und der günstigte RX (50MHz, kein Float) soll auch ca 1 eu kosten. Renesas will die gegen die ARMCM3 positionieren.) Selbst die grösseren RX kosten auch nur ca 6..8eu. (Hängt auch sehr von Speichergrösse ab) ------- Es gibt aber auch weitere uC-Hersteller mit schnellerem Flash. (20..25MHz ist wohl das langsamste überhaupt!)
> (Bist wohl zu sehr auf ST reingefallen)
Wieso ST ??
Alex schrieb: >> (Bist wohl zu sehr auf ST reingefallen) > > Wieso ST ?? Ich bin auch auf ST reingefallen und bereue es nicht g
Alle reden hier vom STM32F2xx. Woher bekommt ihr denn diese? Wer verkauft sie? Wie schon gesagt wurde hat sie nichtmal Farnell. Sonnige Grüße
Als Firma z.B. hier: http://www.ebv.com/index.php?L=0&no_cache=1&id=58&tx_ebvsearch_pi1[qs]=1&ct_ref=u6&tx_indexedsearch[sword]=stm32F2&tx_indexedsearch[results]=5&tx_indexedsearch[lang]=&search_est=ce034c707f8038b0296b7feee7dc80e1 Oder als Sample von ST.
MCUA schrieb: > Asserdem hat ARM-CM3 weder DSP-Funktionen noch FloatingPoint. Dann nimmt man eben Cortex-M4(F).
Michael G. schrieb: > STM-Einsteiger schrieb: >> -Worin genau liegt der Unterschied zwischen SWD und JTAG Debugging ? > > JTAG ist viel älter als SWD und erlaubt im Prinzip das Kaskadieren > mehrerer Bausteine (macht das heute noch wer?). Das kann SWD soweit ich > weiß nicht. Nein, externe Kaskadierung geht mit SWD nicht. Intern sind natürlich viele Komponenten mit dem SWD verbunden. Man kann durchaus mehrere Kerne und andere Debug Komponenten mit SWD ansprechen. -- Marcus
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.