Hallo, bei der Suche nach einer leistungsfähigeren Alternative zu AVR ATMegas bin ich oft auf die Aussage gestossen, dass ARM prozessoren "kompliziert" seinen und "für Anfänger ungeeignet". Was macht ARMs denn so kompliziert? Grüsse Piet
Hauptsächlich die Hardware rund um den ARM. Die ist bei jedem Mikrocontroller anders, und scheint meist haarsträubend umständlich zu sein. Dann werden ARM Controller auch noch meistens in C programmiert, was bedeutet, dass Du Dich erst mal mit Dingen wie Linker-Skripten auseinandersetzen musst, falls das noch nicht jemand für den konkreten Controller gemacht hat. Wenn Du wirklich Rechenleistung brauchst, nimm einen Raspberry Pi oder so was, und mach hardwarenahe Sachen in einem extra Controller den Du per UART ansteuerst. Das ist einfacher, wenn Du schon Erfahrung mit unixoiden Systemen hast.
Piet schrieb: > Was macht ARMs denn so kompliziert? Nix. Wenn Du Dich vom ATMega zum ATXMega umstellen kannst, dann sind die paar Kleinigkeiten zu einer ARM auch kein Hinderniss. In diesem Forum wird oft gern mystifiziert. Ein Rasperry-Pie als nächstbeste Alternative zu einem AVR ist der dämlichste Vorschlag, den man an dieser Stelle machen konnte.
Christian Berger schrieb: > Dann werden ARM Controller auch noch meistens in C programmiert, was > bedeutet, dass Du Dich erst mal mit Dingen wie Linker-Skripten > auseinandersetzen musst, falls das noch nicht jemand für den konkreten > Controller gemacht hat. Und andere Controller werden nicht in C programmiert? ^^
Wenn du es einfach haben willst nimm einen mbed. Einfacher kann man es nicht haben. Ansonsten ist die NXP Entwicklungsumgebung auch nicht kompliziert. Installieren, programmieren, flashen. Da gibts dann z.B. die LPCXpresso Boards für kleines Geld.
ich würde dir für den einstieg ein lpc xpresso empfehlen da bekommst einen debugger und einen großen cortex m3 oder m0 je nach dem für ~25€ da hast du eine fix fertig entwicklungsumgebung für linux/windows da bekommst du anleitungen und tutorials und beispielprogramme alles mit.. also der Einstieg ist da nicht sonderlich schwer... mfg http://www.watterott.com/de/LPC1769-LPCXpresso-Board <- mit dem hab ich begonnen!
Sind sie doch gar nicht. Ich musste mich letztes Semester mit CAN beschäftigen. Da hat sich die Frage gestellt, welchen Controller ich nehme, um mit CAN etwas herumzuexperimentieren. Erst wollte ich das Board von Olimex mit AT90CAN drauf nehmen. Dann bin ich auf das STM32F4 DISCOVERY board gestoßen. Das Board kostete weniger und hatte sogar ein Beschleunigungssensor drauf, also hab ich es genommen. Nach einer zweitägigen Suchen nach einer guten IDE, habe ich die von CooCox genommen (CoIDE ist perfekt, mittlerweile gibt es sogar die kompletten Libs auch für Cortex M4 integriert) Nach einem Einarbeitungstag habe ich bereites UART und CAN am Laufen, zwar nicht Interrupt gesteuert, aber immer hin. Ich finde, dass man mit den fertigen Libs von STM sehr gut arbeiten kann und man kommt auch schnell zu einem Ergebnis.
Der ARM-Befehlssatz wurde zwar immer etwas verbessert, ist aber im Grunde schon uralt, und veraltet.
Christian Berger schrieb: > Hauptsächlich die Hardware rund um den ARM. Die ist bei jedem > Mikrocontroller anders, und scheint meist haarsträubend umständlich zu > sein. > > Dann werden ARM Controller auch noch meistens in C programmiert, was > bedeutet, dass Du Dich erst mal mit Dingen wie Linker-Skripten > auseinandersetzen musst, falls das noch nicht jemand für den konkreten > Controller gemacht hat. > > Wenn Du wirklich Rechenleistung brauchst, nimm einen Raspberry Pi oder > so was, und mach hardwarenahe Sachen in einem extra Controller den Du > per UART ansteuerst. Das ist einfacher, wenn Du schon Erfahrung mit > unixoiden Systemen hast. Selten so einen Bullshit gelesen.
Piet schrieb: > Hallo, > > bei der Suche nach einer leistungsfähigeren Alternative zu AVR ATMegas > bin ich oft auf die Aussage gestossen, dass ARM prozessoren > "kompliziert" seinen und "für Anfänger ungeeignet". > > Was macht ARMs denn so kompliziert? > > Grüsse > Piet Wenn man sich wirklich von Anfang an mit Startup und Linkerscripten beschäftigt, dauert es lange bis wirklich alles läuft. Verwendet man dagegen fertige Pakete (Ich habe mit LPCXpresso angefangen) kommt man mit den modernen Cortex MUCs min. genauso schnell wie mit dem AVR ans Ziel. Die Perepherie habe ich schnell gelernt in dem ich die mitgelieferten Libs und das User Manual studiert habe. Wenn man alles halbwegs beherrscht, dann kann man immer noch anfangen Startup und Linkerscripte anzupassen. Großer Vorteil ist halt das mit den LPCXpressos und den STMDiscoveryboards und evtl. auch mit dem neuen TI Launchpad, gleich einen ordentlichen Debugger mitkommt. Das vereinfacht imho den start enorm.
MCUA schrieb: > Der ARM-Befehlssatz wurde zwar immer etwas verbessert, > ist aber im Grunde schon uralt, und veraltet. Stimmt, der native ARM-Mode hat ein paar Fehler. Aber ist das für C-Programme soo wichtig? Zumal man heute eher die Cortex-M Geräte in ihrem Thumb2-Mode anpeilt, und für die gilt das nicht.
Das SimpleCortex Projekt ist auch einen Blick Wert: http://www.brc-electronics.nl/ Dort ist der Debugger für die CooCox-IDE mit auf dem Board. Neben Ethernet und SD-Karte. Dieser Debugger hat den Vorteil, dass er auch unter Keil und IAR laufen soll. Der lpc-link auf dem XPresso-Boards ist zwar nett aber ausschließlich mit der LPCXPresso Umgebung von CodeRed kompatibel. Für die kleinen M0 ist das auch interessant: http://de.farnell.com/jsp/search/productdetail.jsp?sku=2136555 EMBEST - COLINKEX_LPC11C14 EVB - BORD Da ist wieder neben dem Debugger ein LPC11C14 + Can Transiver drauf. Ideal um zusammen mit der CooCox-Ide ins Cortex Geschäft einzusteigen. Da diese Ide auch direkt mit dem St-Link Debug Adapter auf den Evalueboards von ST umgehen kann, hat man wenigstens nur eine IDE wenn man sich noch nicht zwischen STM32 und NXP LPC entschieden hat. Die Attolic True Studio Geschichten für STM32 würde ich auf Grund der 32k Begrenzung nicht mehr anfassen.
ARM ist sogar einfacher als AVR :-) Für den Einsteiger macht ein Board Sinn, das mit vielen Programmbeispielen kommt, die sofort laufen, gut kommentiert sind, und die man dann selbst debuggen kann. Ich habe mit diesem Board angefangen, alles drauf (Display, ADC, DAC, CAN, USB, Ethernet), und 100 Beispiele: https://www.olimex.com/Products/ARM/NXP/LPC1766-STK
Nimm dir n Cortex-M3, und schau dir CMSIS an. Dort wird dafür gesorgt, dass du bei main() anfangen kannst, zu programmieren, wie du das vom AVR her gewohnt bist. Wichtig ist nur, dass du die Peripherals (UART zB) vorher einschaltest (bei STM war das glaub ich APB2ENR), sonst werden die aus Stromspargründen nicht geclockt und du landest ggf. im Hard Fault. Die CMSIS hilft dir auch bei der config des Interrupt Controllers (NVIC), siehe dazu core_cm3.h Willst du einen vernünftigen JTAG/SW Debugger, mit dem du flexibel bist, dann kaufe dir von Segger den JLink Edu (rund 50,-), dann kannst du mit sämtlichen GNU's, Keil MDK, IAR und sonstigen spielen. Meine persönlichen Lieblinge sind der STM32F103ZE (Keil MCBSTM32E) und der LPC1768 (Keil MCB1700), mit MDK/RL-ARM und ULINK pro :-) VG, /th.
Lothar schrieb: > ARM ist sogar einfacher als AVR :-) Das sagt doch keiner!!! Ich meine aber, dass man nach auch mit einem ARM - anfangen könnte, weil es nicht so viel komplizierter ist. Man hat ja wie gesagt, gut aufbereitete Bibliotheken zur Ansteuerung der Peripherie. Man muss nur die Dokus der Bib's sich gut anschauen und dann geht es. Wo ich letztes Semester mit ARM anfing, haben mich die Bib's irgend wie an Arduino Zeugs erinnert. Ach ja genau, wenn wir schon von einem sehr einfachen einstieg reden, dann sind die Arduinos meiner Meinung nach eine sehr gute Wahl. Die sind in Deutschland zwar etwas teuer, aber wenn man über www.aliexpress.com/ aus China bestellt, dann nicht mehr. Da gibt es auch viel dazu passende Sensoren, Displays und so weiter.
Ich war bis vor einen Jahr noch gelegentlicher Bascom Programmierer und beschäftige mich nun schon lange mit ARM, speziell mit STM32F4. Was das umsteigen wirklich "schwer" macht ist: 1. Die Frage womit Programmieren. Denn die Beispiele von ST sind ausschließlich nur mit sehr teuren IDE sofort lauffähig. Es sei denn man benutzt eine Kickstart Version die auf 32K beschränkt ist. 2. Die Libs sind sehr aufgebläht und man braucht lange um da überhaupt mal durch zu blicken. 3. Es gibt kein wirklich gutes Buch was einen Schritt für Schritt da heran führt. Schon gar nicht in Deutsch. Aber was es WIRKLICH schwer macht. Man will am Anfang immer viel zu viel. Mein Fazit. Fange nicht mit ARM an weil du eine Lösung suchst, sonder einfach nur um ARM zu lernen. Ich würde mir an deiner Stelle ein STM32F4Discovery besorgen. Kostet keine 20 Euro. Wenn du danach googlest wirst du vieles dazu finden. Dann als IDE die Cocoox IDE herunter laden und damit anfangen.Braucht nicht erst umständlich eingerichtet werden wie Eclipse. Kostet nichts, wird weiter entwickelt. Unterstützt viele Hersteller. Gruß Jörg .
Ich finde, ARM und andere leistungsfähige Mikrocontroller (Infineon XE/XC-Serie) sind, bis auf den Hardwareaufwand in der Programmierung wesentlich einfacher. Man kann sogar sprintf verwenden, dividieren und multiplizieren und sich in C austoben ohne schlechtes Gewissen, denn kaum einer wird es schaffen, die Geschwindigkeits-Limits auszunutzen - an die man bei 8-Bittern mit C relativ schnell herankommt (Beispiel: sprintf geht auf vielen kleinen PICs bei MikroC nicht, da der Speicher nicht ausreicht). Was den Hardwareaufwand betrifft: Nur TQFP-Packages, manchmal mehrere Versorgungsleitungen, nicht tolerant gegen Misshandlung (Überspannung, Verpolung, ...) und nur 3.3V (manche sind 5V-tolerant was die IOs betrifft) C auf 8-Bittern wie AVR mag ganz nett sein, aber ich finde, man sollte es nicht übertreiben. Einen Webserver würde ich daher eher auf einem ARM implementieren, auch wenn es für den AVR einen C-Compiler, Chips mit 128K Flash und Webserver-Projekte gibt. Ein weiterer Vorteil der ARMs ist: Du bekommst massig Flash und RAM zum einem billigeren Preis als bei 8-Bittern. Ein ATMEGA1284P kostet mehr als ein wesentlich leistungsfähigerer ARM mit mehr Flash und RAM.
Jörg B. schrieb: > > Mein Fazit. Fange nicht mit ARM an weil du eine Lösung suchst, sonder > einfach nur um ARM zu lernen. > > Ich würde mir an deiner Stelle ein STM32F4Discovery besorgen. Kostet > keine 20 Euro. Wenn du danach googlest wirst du vieles dazu finden. > > Dann als IDE die Cocoox IDE herunter laden und damit anfangen.Braucht > nicht erst umständlich eingerichtet werden wie Eclipse. Kostet nichts, > wird weiter entwickelt. Unterstützt viele Hersteller. Das ist mal eine richtig gute Empfehlung!!!Würde ich so sofort unterschreiben!!
oder man nimmt gleich SAM4S Xplain Kit (kostet auch keine 30$) und hat SAM-ICE integriert, div. Sensoren drauf, Touch usw. und man kann diverse Module draufstecken wie Zigbee Transceiver Module (vom RZ600 Kit), Wifi Module (von Redpine oder H&D), Sensor module wie das Osram Proximity Sensor board, oder boards mit 3D-ACc., Barometer, Kompass usw. Atmel Studio 6 installieren und innerhalb von Minuten kann man ein erstes Projekt starten. Riesen Vorteil: Subversion zur Versionskontrolle kann per Plugin integriert werden - damit kann man vor/zurück "blättern" in verschiedenen Experimenten ohne nervige Kopiererei von Ordnern.
Genau Suberversionskontrolle ist genau das was ein Anfänger braucht. Genauso wie WIFI 3D-ADCs usw. :D Atmel Studio ist zwar eine prima Sache. Sehr Modern und komfortabel weil es auf Visual Studio aufsetzt. ABER man ist dann wieder auf einen Hersteller festgelegt.
A. M. schrieb: >> Ich würde mir an deiner Stelle ein STM32F4Discovery besorgen. Kostet >> keine 20 Euro. Wenn du danach googlest wirst du vieles dazu finden. >> >> Dann als IDE die Cocoox IDE herunter laden und damit anfangen.Braucht >> nicht erst umständlich eingerichtet werden wie Eclipse. Kostet nichts, >> wird weiter entwickelt. Unterstützt viele Hersteller. > > > Das ist mal eine richtig gute Empfehlung!!!Würde ich so sofort > unterschreiben!! Na ja, ich würde das so nicht unterschreiben. Das ist wie Fahrschule auf einem Forme 1 Wagen. Wenn man den Schritt von 8 nach 32 Bit machen will, ist das STM32VLDISCOVER deutlich besser geeignet. Mit der Doku zum STM32F1xx hat man schon genug für lange Winterabende. Coocox hat außerdem keine Registerdefinitionen für den STM32F4xx. Das heißt, das Fenster was sonst die SFRs im Debugger anzeigt bleibt leer. Ist am Anfang nicht so schön. Wenn man Ethernet will, fehlt beim STM32F4Discovery der PHY. Mir fallen für diesen Boliden außer Audio und co. nicht viele Anwendungen ein, die dessen Power auch benötigen.
@ OP: Dieselbe Frage stellte ich mir vor ein paar Monaten auch :-) Ich habe mir damals auch das STM32F4DISCOVERY gekauft und mir Eclipse passend eingerichtet (wir verwenden hier ausschließlich Linux). Dafür gibt es auch passende Tutorien. Die Einarbeitung ist nicht sooo schwer und auch nicht so dramatisch anders als bei AVRs. Wichtig ist, dass man langsam anfängt: also erstmal LED blinken lassen, die Fähigkeiten der Ports kennenlernen, dann vielleicht mal einen Timer programmieren usw. - und irgendwann mal die "hohen Weihen" DMA etc. Für mich waren die STM-Libs sehr hilfreich - andere verfluchen sie ;-) Linkerskripte sind nicht dramatisch - das macht Eclipse automatisch (wenn man die Anleitungen befolgt :-), so dass man schnell Erfolgserlebnisse hat. Wenn Du etwas mehr Geld ausgeben möchtest/kannst: wir haben uns dieses Set hier für etwa 107 Euro bestellt - da ist ein STM32F4DISCOVERY mit dabei, dazu eine Menge Module, um nach Herzenslust zu testen und zu basteln: http://www.wvshare.com/product/Open407V-D-Package-B.htm Die gibt es übrigens auch bei ebay. Es gab hier auch neulich einen Thread, wo jemand diese Module benutzte: Beitrag "STM32F4 overclocken" Chris D.
Christian Berger schrieb: > dass Du Dich erst mal mit Dingen wie Linker-Skripten > auseinandersetzen musst, Daran verging bei mir mal gut eine Woche, ungelogen! Es war zu der Zeit, als Keil gerade von ARM gekauft wurde. Es war nicht leicht, im Netz Linker-Beispiele zu finden. Normalerweise braucht man nicht zwingend ein Linker-Script, aber wir mußten verschiedene Code-Bereiche an bestimmte Adressen legen. Dann hat der ARM verschiedene Modes wie Exceptions und Interrupts, aber auch teils umschaltbaren ARM- und Thumb-Mode für Code. Übrigens ist es kein RISC, sondern ein CISC, Complex Instruction Code. Aber man kommt damit zurecht, wenn man vorher auf einem 8051 arbeitete. Ich erfreute mich sogar an Assembler-Schnipseln. Beim Assembler muß man auch vorsichtig agieren, denn es ist eine Pipelined-Maschine. Bei Chinesen und Koreanern fand ich im Internet die besten Assembler-Beispiele. In Europa und USA nicht. So profitiert und lernt man auch mal von Chinesen, es muß nicht immer umgekehrt sein. Die Codegrößen beeindruckten mich gelegentlich. Teils 2 Befehle, wofür man beim 8051 eine Riesen-Schlange Code generieren muß. So machte der 32-Bitter richtig Spaß. Es waren bei mir übrigens die LPC21xx von NXP, mit denen ich es zu tun hatte. Atmel versuchte uns mal mit ARM zu bekehren, aber die vielen 8- und 16-bit-Register gefielen mir nicht. Was macht man im 32-Bitter mit 16-bit-Timern? Die hat man auch im 8051. Das ist beim LPC2000 durchgängig in 32 bit gehalten. OK, das ist 5 Jahre her, da hat sich inzwischen sicher überall noch was getan. Für den ARM spricht die weltweite Verbreitung in vielen µC vieler Hersteller. D.h., man würde bei einem Umstieg immer wieder einen alten Bekannten finden. Wenn ich mal vom 8051 bekehrt werden sollte, im Augenblick reichen sie mir, dann überlege ich wieder sowas wie die LPC2000. Bzw. was mit ARM-Cortex.
Wilhelm Ferkes schrieb: > Teils 2 Befehle, wofür > man beim 8051 eine Riesen-Schlange Code generieren muß. Geht aber auch umgekehrt, z.B. 8051: "MOV P1.3, C". Lade atomar einen IO-Pin mit dem Carry-Bit. Das dürfte den ARM ne Menge Befehle kosten. Es gibt nicht die CPU für alles. Steueraufgaben lassen sich mit 8Bittern oft erheblich einfacher lösen. Peter
NUTOS (http://www.ethernut.de/) im aktuellen SVN Head (http://ethernut.svn.sourceforge.net/viewvc/ethernut/trunk/) kennt viele AVR8, AVR32, AT90, AT91, NXP17 und STM32 Bausteine und Boards. Nach dem Bauen der Konfigurationsdateien und dann der Bibliotheken für das Board kann man dann schnell einigermassen portable Programme schreiben, ohne sich um viele Details wie einer formatierten Ausgabe mit fprintf oder das Schreiben eines Schedulers kümmern zu müssen. Durch die kooperativen Threads muss man sich auch nicht zu viele Gedanken um die Datenkonsistenz machen. Selbst das HTTP Server Beispiel ist portable.
> Was macht ARMs denn so kompliziert? Nichts. Ein Projekt mit einem CortexM3 ist mit geeigneter IDE genauso schnell umsetzbar wie ein Projekt mit einem AVR bei gleichem Anfangskenntnissstand. Ich habe das selbst erlebt, als ich zwei Leuten den STM32 nahegebracht habe. Die Hürden sind sehr gering, da es für ein paar Euro gute Evalboards gibt und die IDE komplett kostenfrei ist (Coocox)
Tja, also ich hab mich vor Kurzem auch mal in die ARM Richtung begeben. Ich hab eigentlich von 0 auf fast 100% an einem Tag geschafft. Benutzt habe ich * Codesourcery G++ Lite von Mentor Hier steckt der ARM-Compiler drin und diverse Tools (heißt alles zusammen "Toolchain") drin, die für das Bauen von Binaries für ARM Prozessoren notwendig sind. Das heißt hiermit lassen sich Binaries für alle üblichen ARM Prozessoren erzeugen. Diese Toolchain wird dabei ganz gut von "Mentor" gepflegt und ist sehr aktuell * Eclipse mit CDT Plugin für C/C++ Entwicklung Hier hackst du den Code ein, statt Eclipse könnte man theoretisch auch einen normalen Texteditor nehmen. * GNUARM Plugin für Eclipse Hier wird Eclipse dann praktisch. Mit dem Plugin kann man gängige ARM Toolchains in Eclipse einbinden und hat für Compileroptionen und Co dann eine grafische Oberfläche * OpenOCD als Programmiertool Hiermit wird das Binary auf den ARM übertragen. Das "schwierigste" war Linkerscripts und Startup Code zu schreiben. Hier gibts im Gegensatz zu den AVRs nichts fertiges, sondern man muss für jedes Projekt ein neues Linkerscript basteln, bzw. ein bestehendes auf die Eigenschaften des neuen Prozessors abändern. Man bekommt jedoch bei den Chipherstellern üblicherweise Pakete mit Scripts drin, die man dann als Vorlage nehmen kann. Ich muss aber auch gleich Vorweg sagen, dass ich nicht vor habe irgendwelche Libraries von den Chipherstellern zu benutzen (in meinem Falle war das die STM32 StdPeriph Library). Diese sind öfter mal buggy und schlecht zu durchschauen. Ich programmiere lieber mit dem CMSIS Headerfile zu dem entsprechenden Chip (Das Pendant zu <avr/io.h>) und dann weiter auf Registerebene nach Datenblatt.
Also ich komme mit den Teilen von TI sehr gut zurecht. zb: http://www.ti.com/tool/eks-lm3s1968 Haben auch eine komplette unbegrenzte IDE (wenn man den CodeComposerStudio auswählt) inklusive Debugger und sehr umfangreiche und gut dokumentierte Bibliotheken dabei. Außerdem gibt es ein freies RTOS für den µC direkt mit dazu.
Liebe Leute, vielen Dank für all die guten Tipps! Ich werde mich an einem SimpleCortex probieren - bin gespannt. Grüsse Piet
Beim SimpleCortex ist die Auswahl an Tutorials und Beispielen bestechend, es scheint alles sorgfältig dokumentiert. http://www.brc-electronics.nl Ausserdem sind alle Ausgänge rausgeführt, die ich brauche, und die Geometrie ist Arduino Shield kompatibel...
Weil ARM den grässlichen LD/ST-Flaschenhals hat (*) sind fast immer etliche Mem-zugriffe ZUSÄTLICH nötig, was viele Takte kostet und die Sache unterm Strich (egal bei wieviel Bits) viel langsamer macht. Schon deshalb halte ich diese Architektur (zumindest im typ Embedd-Bereich) für veraltet. (*)auch schnelle IO-Befehle, bsp CM0+, ändern daran nichts
Und selbst bei LD/ST-Befehlen ist nichtmal ein 16-bit-disp möglich, was (oft) schon wieder ZUSÄTLICHE Takte/Befehle nötig macht.
Und wieder eine Runde RISC-CISC Fight. Ich dachte, das hätte sich in mittlerweile 2,5 Jahrzehnten langsam gelegt. ;-)
Peter Dannegger schrieb: > Wilhelm Ferkes schrieb: >> Teils 2 Befehle, wofür >> man beim 8051 eine Riesen-Schlange Code generieren muß. > > Geht aber auch umgekehrt, z.B. 8051: "MOV P1.3, C". > Lade atomar einen IO-Pin mit dem Carry-Bit. > Das dürfte den ARM ne Menge Befehle kosten. Bzw. eher eine Menge Datenbits, weil er keine Einzelbits verarbeiten kann. Dazu fand ich in einem uralten Buch von 1987 was interessantes, der Autor war noch bei VALVO Hamburg: Anhand von zwei Beispielen wurde eine EXOR-Verknüpfung von 2 bits im 8051 gezeigt. Dummerweise hat der ja für den Einzelbitprozessor nicht den XRL-Befehl, man mußte die Verknüpfung mit ANL und ORL und Negierungen schrittweise machen. Aber es wurde nur mit dem Bitprozessor gearbeitet, ohne Bittests und bedingte Verzweigungen, und im weiteren Beispiel gezeigt, wie man diesen Code mit einem Bittest und Sprungbefehl noch halbieren kann. D.h., der Bitprozessor alleine ist auch nicht immer das optimalste. Man mußte ja damals noch jedes Byte sparen, wo es nur geht, weil die gängigen EPROMs meist 2-8k Bytes hatten. Heute würde man sagen: Krümelsucherei. Interessant aber trotzdem. Zur Zeit plage ich mich in Assembler selbst noch mit so einer alten Mühle mit 4k EPROM. Zum Wegwerfen ist das Board aber zu schade, es funktioniert ja einwandfrei. Und einiges bekommt man mit Assembler schon auch in die 4kB hinein. Der 8051 war ja auf Assembler und sparsamen Code getrimmt, man beachte die 1-Byte-Befehle. Das stammt wohl noch aus der Zeit des 8048, als man wirklich auch mal nur 256 Byte EPROM hatte. Ebenfalls schaue ich mir zur Zeit ein SiLabs-8051-Derivat an, das ich auf einem Demo-Board habe. Gigantische 128k SRAM, und das Ding hat einen ADC mit DMA, der direkt ohne den Prozessor ins RAM schreibt. Das ist ebenfalls sehr interessant, hat aber außer dem Core wirklich nicht mehr soviel mit dem Ur-8051 zu tun. Es war mal ein Geschenk eines Vertreters von einem Distributor, einem geschenkten Gaul schaut man nicht ins Maul, werde mich damit auch mal näher befassen. Etwas komplexer von der Handhabung ist es schon, alleine die Crossbar zur Pinkonfiguration, oder die multiplen SFR-Pages. > Es gibt nicht die CPU für alles. > Steueraufgaben lassen sich mit 8Bittern oft erheblich einfacher lösen. Du meinst mit sowas wie dem 8051, der einen Bitprozessor und eine Menge Flags hat. Das ist richtig. Die vielen Flags sind schon oft optimal als Merker. Dennnoch würde ich auch einen ARM für solche Aufgaben verwenden, und über eine Struktur ein Doppelwort in 32 bits zerlegen. Sowas machte ich mit dem ARM auch schon, klappt genau so gut wie wirklich einzelne Flags. Was solls, wenn man heute Megabyte Codespeicher hat. Die Speicher werden immer riesiger, so daß man kein Byte mehr sparen muß. Über dies machte ich dann auch noch einen Performancetest des LPC2000 gegen ein SiLabs-Derivat mit 8051-Kern. Der ARM schnitt auch noch im Energieverbrauch erheblich günstiger ab, auch wenn man erst das Gegenteil annehmen möchte. > Peter Wilhelm
Wieviele Prozent eines Controller-Programms von beispielsweise 50KB (optimierter) Grösse machen komplexe Bit-I/O? Und wird das absolut gemessen mehr, wenn das Programm weiter wächst?
Peter Dannegger schrieb: > 51 Peter Dannegger schrieb: > Geht aber auch umgekehrt, z.B. 8051: "MOV P1.3, C". > Lade atomar einen IO-Pin mit dem Carry-Bit. > Das dürfte den ARM ne Menge Befehle kosten. > Wir reden hier von Cortex M3/4. Dort gibt es Bitbanding was atomar auf einzelen Bits zugreifen kann.
Wilhelm Ferkes schrieb: > Dummerweise hat der ja für > den Einzelbitprozessor nicht den XRL-Befehl, man mußte die Verknüpfung > mit ANL und ORL und Negierungen schrittweise machen. Hab ich noch nie so probiert. Ich machs immer auf die einfache Art ("jnb BIT1", "cpl BIT2"). Wilhelm Ferkes schrieb: > Zur Zeit plage ich mich in Assembler selbst noch mit so einer alten > Mühle mit 4k EPROM. Inzwischen haben viele 8051 ja 64kB Flash. Mein größtes C-Programm braucht auch nur 40kB (seit 1995 gewachsen). Damals war es ein 80C652 + extern EPROM, SRAM, jetzt ist es ein AT89C51RE2. Was mich am ARM7 stört, sind diese umständlichen SET- und CLEAR-Register. Beim Cortex M3 soll man das ja nicht mehr benötigen, der kann ein oder mehrere IO-Bits gleichzeitig ändern. Peter
Peter Dannegger schrieb: > Wilhelm Ferkes schrieb: > >> Dummerweise hat der ja für >> den Einzelbitprozessor nicht den XRL-Befehl, man mußte die Verknüpfung >> mit ANL und ORL und Negierungen schrittweise machen. > > Hab ich noch nie so probiert. Ich machs immer auf die einfache Art ("jnb > BIT1", "cpl BIT2"). OK, ich nenne das besagte Beispiel mal, damit du besser siehst, was ich meine. E1 und E2 sind Eingänge Flags, der Ausgang ist Carry. Die Wahrheitstabelle EXOR kennst du ja.
1 | MOV C, E2 |
2 | ANL C, /E1 |
3 | MOV F0, C |
4 | MOV C, E1 |
5 | ANL C, /E2 |
6 | ORL C, F0 |
7 | |
8 | ; das selbe optimiert: |
9 | |
10 | MOV C, E2 |
11 | JNB E1, $+4 |
12 | CPL C |
> Beim Cortex M3 soll man das ja nicht mehr benötigen, der kann ein oder > mehrere IO-Bits gleichzeitig ändern. Sowas sollte ich mir echt mal zu Weihnachten gönnen, wenn auch Selbstbeschenkung. ;-)
Peter Dannegger schrieb: > Beim Cortex M3 soll man das ja nicht mehr benötigen, der kann ein oder > mehrere IO-Bits gleichzeitig ändern. Mit dem ARM Bitbanding des Cortex M3 geht immer nur 1 Bit auf einmal. Für mehrere Bits gleichzeitig wirds wieder herstellerspezifisch. NXP verwendet ein Maskenregister, ST kombiniert 16 Set- und 16 Reset-Bits in einem 32-Bit Register, bei den LM3 werden 8 Bits aus der Adresse als Maske verwendet. So können mehrere Bits gleichzeitig auf beliebige Werte gesetzt werden.
A. K. schrieb: > NXP verwendet ein Maskenregister, Bei den LPC2000 konnte man wohl IOPIN direkt lesen und beschreiben. Aber ich muß das nachschauen, weil länger her.
Wilhelm Ferkes schrieb: > Sowas sollte ich mir echt mal zu Weihnachten gönnen, wenn auch > Selbstbeschenkung. ;-) Mach das! Besorgt Dir ein STM32F4DISCOVERY. RS bietet die für 12,xx netto an. Wenn Du schon Controller programmiert hast, dann sollte der Einstieg nicht allzu schwer fallen. Häng Dich da rein, Du hast doch die Zeit. Und dann bietest Du Deine Dienste als STM32-Spezialist an. Gute Leute in dem Bereich werden gesucht. Chris D.
Chris D. schrieb: > Wilhelm Ferkes schrieb: > >> Sowas sollte ich mir echt mal zu Weihnachten gönnen, wenn auch >> Selbstbeschenkung. ;-) > > Mach das! > Besorgt Dir ein STM32F4DISCOVERY. RS bietet die für 12,xx netto an. > > Wenn Du schon Controller programmiert hast, dann sollte der Einstieg > nicht allzu schwer fallen. > > Häng Dich da rein, Du hast doch die Zeit. > > Und dann bietest Du Deine Dienste als STM32-Spezialist an. > > Gute Leute in dem Bereich werden gesucht. > > Chris D. Danke, Chris. Das Hobby und die Materie kann mir nichts und niemand vergällen, und es macht mir wieder Spaß. Ich war ja schon total auf Null abgesackt, und fast reif für unter die Erde. Bei augenblicklicher Gesundheitsstörungen, wo erwerbsmäßig so gut wie nichts läuft. Ich war heute beim Hartz-Amt, und die Beraterin weiß bei allen ungeklärten Gesundheitsumständen im Augenblick überhaupt nichts mit mir anzufangen, verschob einfach die Dinge auf einen neuen Termin in ein paar Monaten. Wenigstens war das Gespräch dort fair und freundlich. Wer weiß? Ich bin gerade dabei, zu lernen, daß Zukunftsdenken nicht alles ist, aber noch einiges sein kann. Allerdings, bei dem schönen STM32-Board fehlt mir sicher wieder eine relativ unlimitierte Entwicklungsumgebung, wenn ich keine Vollversion für 3000€ kaufen will. Bezahlen kann ich teuere Tools im Augenblick nicht. Und: Bekomme ich bei RS was als Privatmann? Sonst hatte ich immer mal die Olimex-Boards im Auge, z.B. hier aus dem Forums-Shop. Sie sind erheblich günstiger als beispielsweise ein Keil MCB2100.
Wilhelm Ferkes schrieb: > A. K. schrieb: > >> NXP verwendet ein Maskenregister, > > Bei den LPC2000 konnte man wohl IOPIN direkt lesen und beschreiben. Aber > ich muß das nachschauen, weil länger her. Klar, aber das bringt nichts ein, weil man nur selten 32 Bits gleichzeitig setzen will und für partielle Modifikation getrennte Loaad und Store-Befehle braucht - was in Verbindung mit Interrupts arg ungünstig ist. Ausserdem besteht der Sinn dieser Methoden auch darin, beispielsweise 4 LCD-Bits in einem Rutsch definieren zu können, auch wenn sowohl 0 wie 1 drin vorkommt.
Wilhelm Ferkes schrieb: > Danke, Chris. Das Hobby und die Materie kann mir nichts und niemand > vergällen, und es macht mir wieder Spaß. Siehste. Mach es wie ich und Dein Hobby zum Beruf :-) > Ich war ja schon total auf Null > abgesackt, und fast reif für unter die Erde. Bei augenblicklicher > Gesundheitsstörungen, wo erwerbsmäßig so gut wie nichts läuft. Ich war > heute beim Hartz-Amt, und die Beraterin weiß bei allen ungeklärten > Gesundheitsumständen im Augenblick überhaupt nichts mit mir anzufangen, > verschob einfach die Dinge auf einen neuen Termin in ein paar Monaten. > Wenigstens war das Gespräch dort fair und freundlich. Wer weiß? Ich bin > gerade dabei, zu lernen, daß Zukunftsdenken nicht alles ist, aber noch > einiges sein kann. Eben. Man sollte schon auch jetzt leben, aber warum nicht mal zu neuen Ufern aufbrechen? So etwas wirkt sich übrigens auch durchaus positiv auf die Gesundheit aus. > Allerdings, bei dem schönen STM32-Board fehlt mir sicher wieder eine > relativ unlimitierte Entwicklungsumgebung, wenn ich keine Vollversion > für 3000€ kaufen will. Wir arbeiten uns gerade unter GNU-GCC-GDB/Eclipse ein - das kostet Dich nur das Durchlesen der Tutorien im Netz und Einarbeitung. Ansonsten benötigst Du wirklich keine finanziellen Mittel. > Bezahlen kann ich teuere Tools im Augenblick > nicht. Und: Bekomme ich bei RS was als Privatmann? Das war nur ein preisliches Beispiel. Es dürfte noch andere Anbieter in ähnlicher Preislage geben. Ansonsten hat hier im Markt neulich jemand diese Boards günstig verkauft. Steckbrett und Strippen für eigene Aufbauten wirst Du ja haben. Ansonsten: Dealextreme - sehr preiswert und passable Verbinder. > Sonst hatte ich immer mal die Olimex-Boards im Auge, z.B. hier aus dem > Forums-Shop. Sie sind erheblich günstiger als beispielsweise ein Keil > MCB2100. Wie auch immer. Hauptsache, Du unternimmst etwas. Dann schreibst Du ein schönes Tutorium über den STM32, wie man mit dem GDB debuggen kann, mit guten Beispielen, erklärst die Takterzeugung, wie man die für Timer berechnet, wie DMA funktioniert usw. und baust Dir daraus eine ordentliche Homepage. Dann schreibst Du Abstraktionsbibliotheken z.B. für Grafikerzeugung und setzt Dich vielleicht mit einem RTOS auf dem STM32 auseinander. Dazu dann noch "Wilhelms Programmschnipsel", wo jede Woche irgendeine einfache pfiffige Routine angeboten wird. Irgend so etwas eben. Und ruckzuck hast Du reichlich Leser, die mit Fragen kommen und Hilfe benötigen. Und da sind dann auch schnell mal Firmen dabei. Du wärst nicht der erste, der so zu Projekten und Arbeit kommt. Finanzieller Aufwand: gleich Null Chris D.
Chris D. schrieb: > Besorgt Dir ein STM32F4DISCOVERY. RS bietet die für 12,xx netto an. Da hier gerade die Spezialisten so schön versammelt sind und ich mit allem Möglichem Erfahrungen habe, bloss nicht ARM, eine konkrete Frage: Kann ich mit dem Discovery auch Hard- und Software für eine Steuerung mit einem NXP LPC1769 o.Ä. entwickeln, oder sollte man da besser ein Kit speziell mit dem gewünschten Prozessor beschaffen? Und umgekehrt, nützt mir eine Ausrüstung für LPC was für STM32? Ich vermute mal der Teufel liegt da wo er immer liegt, im Detail. Ach ja, wenn wir schon dabei sind, bieten eigentlich Hochpreissysteme wie IAR/Keil noch grosse Vorteile? Ein möglicher Kunde hat auch beklagt, bei seinem derzeitigen System (LPC2917) wäre ein Echtzeit-Bestriebssystem im Einsatz, für das er 100 000 Euro bezahlen müsste, um es selbst weiter zu nutzen - macht sowas Sinn? Was soll daran so überlegen sein? Nicht dass ich sowas ernsthaft in Betracht ziehen würde, ich müsste das ja auch den Kunden in Rechnung stellen. Gruss Reinhard
Chris D. schrieb: > Wilhelm Ferkes schrieb: > >> Danke, Chris. Das Hobby und die Materie kann mir nichts und niemand >> vergällen, und es macht mir wieder Spaß. > > Siehste. Mach es wie ich und Dein Hobby zum Beruf :-) > >> Ich war ja schon total auf Null >> abgesackt, und fast reif für unter die Erde. Bei augenblicklicher >> Gesundheitsstörungen, wo erwerbsmäßig so gut wie nichts läuft. Ich war >> heute beim Hartz-Amt, und die Beraterin weiß bei allen ungeklärten >> Gesundheitsumständen im Augenblick überhaupt nichts mit mir anzufangen, >> verschob einfach die Dinge auf einen neuen Termin in ein paar Monaten. >> Wenigstens war das Gespräch dort fair und freundlich. Wer weiß? Ich bin >> gerade dabei, zu lernen, daß Zukunftsdenken nicht alles ist, aber noch >> einiges sein kann. > > Eben. Man sollte schon auch jetzt leben, aber warum nicht mal zu neuen > Ufern aufbrechen? So etwas wirkt sich übrigens auch durchaus positiv auf > die Gesundheit aus. > >> Allerdings, bei dem schönen STM32-Board fehlt mir sicher wieder eine >> relativ unlimitierte Entwicklungsumgebung, wenn ich keine Vollversion >> für 3000€ kaufen will. > > Wir arbeiten uns gerade unter GNU-GCC-GDB/Eclipse ein - das kostet Dich > nur das Durchlesen der Tutorien im Netz und Einarbeitung. > > Ansonsten benötigst Du wirklich keine finanziellen Mittel. OK, das wird wie beim SDCC für den 8051 sicherlich gehen. >> Bezahlen kann ich teuere Tools im Augenblick >> nicht. Und: Bekomme ich bei RS was als Privatmann? > > Das war nur ein preisliches Beispiel. Es dürfte noch andere Anbieter in > ähnlicher Preislage geben. Ansonsten hat hier im Markt neulich jemand > diese Boards günstig verkauft. > > Steckbrett und Strippen für eigene Aufbauten wirst Du ja haben. > Ansonsten: Dealextreme - sehr preiswert und passable Verbinder. Ja, sicher. >> Sonst hatte ich immer mal die Olimex-Boards im Auge, z.B. hier aus dem >> Forums-Shop. Sie sind erheblich günstiger als beispielsweise ein Keil >> MCB2100. > > Wie auch immer. Hauptsache, Du unternimmst etwas. > > Dann schreibst Du ein schönes Tutorium über den STM32, wie man mit dem > GDB debuggen kann, mit guten Beispielen, erklärst die Takterzeugung, wie > man die für Timer berechnet, wie DMA funktioniert usw. und baust Dir > daraus eine ordentliche Homepage. > > Dann schreibst Du Abstraktionsbibliotheken z.B. für Grafikerzeugung und > setzt Dich vielleicht mit einem RTOS auf dem STM32 auseinander. > > Dazu dann noch "Wilhelms Programmschnipsel", wo jede Woche irgendeine > einfache pfiffige Routine angeboten wird. > > Irgend so etwas eben. > > Und ruckzuck hast Du reichlich Leser, die mit Fragen kommen und Hilfe > benötigen. Und da sind dann auch schnell mal Firmen dabei. > > Du wärst nicht der erste, der so zu Projekten und Arbeit kommt. > > Finanzieller Aufwand: gleich Null Von meinen ollen 8051-ern könnte ich mich wirklich mal los eisen. Sag mir endlich mal jemand: Wirf das Zeug weg!!! Und kauf dir für einen Fuffi oder Hunni was neues, topmodernes. Und wenn die Boards mich früher mal 1000 DM gekostet haben. Genau daran hängt man, daß es mal teuer war. Ich habe einen Neffen auf dem Gymnasium, der sich letztens schon mal für ein Medizininformatik-Studium bei E-Technik interessierte, den ich mit den ollen Boards noch begeistern könnte. Man kann darauf über die Cross-Compiler (SDCC) komplett C programmieren, auch wenn man reine PC-Programmierung nicht möchte. Und mal eine LED blinken lassen. Ich hab ja hier alle Hilfe dazu gemacht, Tools, Oberflächen wie Geany, Teraterm als Terminal, den SDCC, Bootloader für den 8051 geschrieben, so daß das auch einfach funktionieren würde... > Chris D. Wilhelm
> Beim Cortex M3 soll man das ja nicht mehr benötigen, der kann ein oder > mehrere IO-Bits gleichzeitig ändern. bestenfalls nur für IO, nicht für Mem. >Mit dem ARM Bitbanding des Cortex M3 geht immer nur 1 Bit auf >einmal. Ja, zwar atomic, aber benötigt auch mehrere Takte. Und irgentwas MATH auf Mem oder IO angewandt geht überhaupt nicht. Der Flaschhals ist immer da! Deswegen veraltet!
MCUA schrieb: >> Beim Cortex M3 soll man das ja nicht mehr benötigen, der kann ein oder >> mehrere IO-Bits gleichzeitig ändern. > bestenfalls nur für IO, nicht für Mem. > Und warum wird z.B. beim STM32F4xx folgendes definiert: #define SRAM1_BB_BASE ((uint32_t)0x22000000) /*!< SRAM1(112 KB) base address in the bit-band region */ #define SRAM2_BB_BASE ((uint32_t)0x2201C000) /*!< SRAM2(16 KB) base address in the bit-band region */ >>Mit dem ARM Bitbanding des Cortex M3 geht immer nur 1 Bit auf >>einmal. > Ja, zwar atomic, aber benötigt auch mehrere Takte. > Mehrere Takte bei 168 MHz gegen einen takt bei 16 MHz? > Und irgentwas MATH auf Mem oder IO angewandt geht überhaupt nicht. > Der Flaschhals ist immer da! Deswegen veraltet! Beim AVR zumindesten sind die Register fuer die Bitmanipulations Befehle im OPCODE kodiert. Da ist mit "Math" auch nichts
Was spricht dann gegen ein komplettes Board für den fast gleichen Preis des Einzelcontrollers? z.B. Carambola-Board
Uwe Bonnes schrieb: > Beim AVR zumindesten sind die Register fuer die Bitmanipulations Befehle > im OPCODE kodiert. Da ist mit "Math" auch nichts Lass mal. Für ihn ist alles veraltet, was nicht von Renesas stammt.
Abdul K. schrieb: > Carambola-Board Das ist doch 1) überhaupt kein ARM und 2) ein SoC um Linux drauf laufen zu lassen. Da ist ein Cortex M3 eher näher an AVRs dran, als an einem SoC.
Ich begriff die Anfrage einfach eher in Richtung welche neue Plattform für kleine Projekte. Der Preis ist jedenfalls kaum zu schlagen. Ethernet-Hausbus z.B.
Reinhard Kern schrieb: > Kann ich mit dem Discovery auch Hard- und Software für eine Steuerung > mit einem NXP LPC1769 o.Ä. entwickeln, oder sollte man da besser ein Kit > speziell mit dem gewünschten Prozessor beschaffen? Nein, lass es. Beide MCs haben zwar einen ARM Kern, aber bei der Peripherie kocht jeder Hersteller sein komplett eigenes Süppchen, so das selbst ein simpler GPIO bei NXP anders behandelt wird als z.B. bei ST. Von Timern und ADCs mal ganz zu schweigen. Du brauchst ein Board mit einem NXP, am besten ein dem Original sehr ähnlichen. Wenn das ein Super-Selbst-Gebritzeltes Echtzeitsystem ist, schau dir mal RTOS an, vermutlich haben die Jungs da gekupfert, bzw. ganze Blöcke übernommen. Wilhelm Ferkes schrieb: > Zur Zeit plage ich mich in Assembler selbst noch mit so einer alten > Mühle mit 4k EPROM. Zum Wegwerfen ist das Board aber zu schade, es > funktioniert ja einwandfrei. Und einiges bekommt man mit Assembler schon > auch in die 4kB hinein. Willem, ich hab mir damals(tm), als ich mit den 8051/31 ne Menge gemacht habe, als erstes ein Board mit 8k EPROM und 8k Static RAM gebaut, wobei im EPROM ein trickiger Monitor war, der Programme per Intel HEX ins RAM gespielt hat. Eine verbogene Vektortabelle konnte IRQs im RAM ausführen und so war es easy, Programmfetzen und -Blöcke zu testen, bevor man sie ins Zielsystem geschossen hat. Ich hab den Monitor mal angehängt, vllt. kann ja jemand was mit anfangen. Die Syntax ist allerdings für einen historischen Assembler namens A51.exe
Piet schrieb: > bei der Suche nach einer leistungsfähigeren Alternative zu AVR ATMegas Hier hatte ich auf eine Alternative zu "ARM" aufmerksam gemacht. Beitrag "Verlosung RX210 Promo-Board" Gerade der RX210 kann wie ein ATmega auch mit 5V betrieben werden. Leistungsfähiger sind dann die RX62 oder RX63 Serien.
> Beim AVR zumindesten sind die Register fuer die Bitmanipulations Befehle > im OPCODE kodiert. Da ist mit "Math" auch nichts Der ist auch verkorkst. >Lass mal. Für ihn ist alles veraltet, was nicht von Renesas stammt. Quatsch. Es geht drum welchen Befehlssatz eine CPU unterstützt, das hat nichts mit bestimmter Firma zu tun. Ausserdem hat auch Renesas veraltete CPUs. Schon alleine, dass eine CPU ein bestimmten IO-Bereich überhaupt hat bzw ganz bestimmte Befehle nur auf IO anwendbar sind, zeigt schon, dass es Flickschusterei ist. Denn dadurch sind (fast) alle MATH-Befehle auf alles was IO ist (und auch auf (kleinere) Mem-Bereiche), eben NICHT anwendbar.
MCUA schrieb: > Und irgentwas MATH auf Mem oder IO angewandt geht überhaupt nicht. > Der Flaschhals ist immer da! Deswegen veraltet! MCUA schrieb: > Quatsch. Es geht drum welchen Befehlssatz eine CPU unterstützt, das hat > nichts mit bestimmter Firma zu tun. Ausserdem hat auch Renesas veraltete > CPUs. > > > Schon alleine, dass eine CPU ein bestimmten IO-Bereich überhaupt hat bzw > ganz bestimmte Befehle nur auf IO anwendbar sind, > zeigt schon, dass es Flickschusterei ist. > Denn dadurch sind (fast) alle MATH-Befehle auf alles was IO ist (und > auch auf (kleinere) Mem-Bereiche), eben NICHT anwendbar. Welche 32-bit Architektur ist deiner Meinung nach dann nicht veraltet?
MCUA schrieb: > Denn dadurch sind (fast) alle MATH-Befehle auf alles was IO ist (und > auch auf (kleinere) Mem-Bereiche), eben NICHT anwendbar. Was ist denn so schlimm daran, dass man nicht den Cosinus eines Temperaturfühlers in einem Befehl berechnen kann? Und welcher Prozessor kann das denn? Ich habe schon viele Architekturen programmiert, aber das ging nie anders als einen i/O-Wert in ein Register oder einen Speicherplatz zu laden und dann weiter zu verarbeiten. Mir ist auch nicht bekannt, dass ein PID-Regler o.Ä. deswegen nicht funktioniert. Gruss Reinhard
Jörg B. schrieb: > Die Frage womit Programmieren. Denn die Beispiele von ST sind > ausschließlich nur mit sehr teuren IDE sofort lauffähig. Es sei denn man > benutzt eine Kickstart Version die auf 32K beschränkt ist. 32K sind für einen Einsteiger doch erstmal genug. Vorteil davon : Es läuft wunderbar miteinander. Ich muss nicht erst 1000 Sachen konfigurieren.
Matthias Sch. schrieb: > Wilhelm Ferkes schrieb: >> Zur Zeit plage ich mich in Assembler selbst noch mit so einer alten >> Mühle mit 4k EPROM. Zum Wegwerfen ist das Board aber zu schade, es >> funktioniert ja einwandfrei. Und einiges bekommt man mit Assembler schon >> auch in die 4kB hinein. > > Willem, ich hab mir damals(tm), als ich mit den 8051/31 ne Menge gemacht > habe, als erstes ein Board mit 8k EPROM und 8k Static RAM gebaut, wobei > im EPROM ein trickiger Monitor war, der Programme per Intel HEX ins RAM > gespielt hat. Eine verbogene Vektortabelle konnte IRQs im RAM ausführen > und so war es easy, Programmfetzen und -Blöcke zu testen, bevor man sie > ins Zielsystem geschossen hat. > Ich hab den Monitor mal angehängt, vllt. kann ja jemand was mit > anfangen. Die Syntax ist allerdings für einen historischen Assembler > namens A51.exe So einen MON8052 habe ich auch. Na, ich hab noch die Optomini-Boards mit dem SAB80C517A, die sind auch in Code und Daten mit Speicher je 64k voll ausgebaut, also 64k EPROM und 64k SRAM. Einer von 2 UARTS der µC hat LWL-Transceiver. Das fand ich auch kaum sonstwo. Der UART ist damit gigantisch schnell, bei Quarz 18MHz eben 1,5 Megabaud. So daß ich aus dreien mal ein Ringnetz bauen könnte. So ganz übel finde ich die alte Scheixe nicht unbedingt, zumal ich da in C arbeite. Den Monitor und Bootloader für HEX-Download habe ich im Quellcode, und selbst an meine Bedingungen optimiert. Vor allem, man flasht damit niemals Flash kaputt, Testcode geht immer ins SRAM. Für ein endgültiges Programm habe ich noch den EPROMMER. Und einige EPROMs. Ich dachte eben mal etwas panisch, ich müßte gelegentlich an was neues dran, wie das STM32F4DISCOVERY. Das schaute ich mir heute näher an. Sehr schön natürlich.
Wenn ich "Monitorprogramm" schon höre, dann bekomme ich die Krise. Haben damals in der Schule mit Z80s rumgefummelt, die sowas hatten. Zu der Zeit war ich aber schon voll in den AVRs mit In-Circuit Programming/Debugging drin. Ein totaler Rückschritt ;-) Die Leute von "damals" tun mir leid. Damals war halt nicht alles besser.
David P. schrieb: > 32K sind für einen Einsteiger doch erstmal genug. > Vorteil davon : Es läuft wunderbar miteinander. Ich muss nicht erst 1000 > Sachen konfigurieren. Und wenn dann die Anwendung etwas größer wird wirft man alles weg, sucht sich ne neue IDE und fängt von vorne an. Oder gibt viel Geld aus. David P. schrieb: >> Die Frage womit Programmieren. Denn die Beispiele von ST sind >> ausschließlich nur mit sehr teuren IDE sofort lauffähig. Es sei denn man >> benutzt eine Kickstart Version die auf 32K beschrän Wenn es nicht gerade ST sein mus. Sieh die mal die Stellaris Evalboards LM3Sxxx von TI an. Kosten zwischen ~50 und 100 € Beim Board gibt es einen Jtag Debugger eine komplette unbegrenzte IDE ( CodeComposerStudio) und ausführliche Libs. Es ist sogar ein freies RTOS für den µC dabei.
Simon K. schrieb: > Zu der > Zeit war ich aber schon voll in den AVRs mit In-Circuit > Programming/Debugging drin. Was machst du denn damit? Deine Denkfehler finden? Indessen, ich gebe zu, es ist etwas bequemer. Bei einem modernen ARM hatte ich mal einen Debugger, der buggy war. Damit macht man dann auch: Nichts. Ansonsten: Nachtrag: Diese Optonet-Mini-Boards mit SAB80517 hatten Ende der 1990-er einen Kaufpreis von 450DM. Ich bestellte nur die Leerplatinen, die es alternativ alleine gab. Das Buch mit Beschreibung und Schaltbildern und Diskette hatte ich schon. Bestellte für die Leerplatinen die Bauteile. Kam dann mit einem Viertel Kosten hin, die Aufbauarbeit nicht gerechnet, aber das war unproblematisch.
MCUA schrieb: > Schon alleine, dass eine CPU ein bestimmten IO-Bereich überhaupt hat bzw Hat ARM nicht. Manche ARM-Cores, und zwar nur die Cortex-M, haben innerhalb des einen Adressraums festgelegte Bereiche mit bestimmten Eigenschaften. Na und? > ganz bestimmte Befehle nur auf IO anwendbar sind, Welche wären das?
Ralph schrieb: > David P. schrieb: >> 32K sind für einen Einsteiger doch erstmal genug. >> Vorteil davon : Es läuft wunderbar miteinander. Ich muss nicht erst 1000 >> Sachen konfigurieren. > > Und wenn dann die Anwendung etwas größer wird wirft man alles weg, sucht > sich ne neue IDE und fängt von vorne an. Oder gibt viel Geld aus. Oder man segmentiert in 32k Blöcken ...
Ralph schrieb: > David P. schrieb: >> 32K sind für einen Einsteiger doch erstmal genug. >> Vorteil davon : Es läuft wunderbar miteinander. Ich muss nicht erst 1000 >> Sachen konfigurieren. > > Und wenn dann die Anwendung etwas größer wird wirft man alles weg, sucht > sich ne neue IDE und fängt von vorne an. Oder gibt viel Geld aus. Quatsch. Es geht doch einfach nur darum am Anfang nicht zu viele Baustellen gleichzeitig aufzumachen. Sobald man ein lauffähiges Programm hat und etwas Erfahrung hat mit dem ARM, kann man ja auch auf eine andere Toolchain/IDE umsteigen. > David P. schrieb: >>> Die Frage womit Programmieren. Denn die Beispiele von ST sind >>> ausschließlich nur mit sehr teuren IDE sofort lauffähig. Es sei denn man >>> benutzt eine Kickstart Version die auf 32K beschrän > > Wenn es nicht gerade ST sein mus. > Sieh die mal die Stellaris Evalboards LM3Sxxx von TI an. > Kosten zwischen ~50 und 100 € > Beim Board gibt es einen Jtag Debugger eine komplette unbegrenzte IDE ( > CodeComposerStudio) und ausführliche Libs. Es ist sogar ein freies RTOS > für den µC dabei. Komplett unbegrenzt? Totaler Unsinn. http://processors.wiki.ti.com/index.php/Licensing_-_CCSv4#Free_Licenses Es gibt eine EVAL License, die kann man zeitbegrenzt nutzen und eine Bundle License: ---- We include a free version of CCS with many of our community boards, DSKs and EVM (Evaluation Module) kits. These kits come with a development board, software and CCS. The CCS will only work with the onboard emulation on the board. ---- Ganz toll. Ansonsten das Gleiche wie bei jedem Hersteller: Eine komplett unbegrenzte IDE kostet ein paar Tausend Dollars.
Simon K. schrieb: > Ganz toll. Ansonsten das Gleiche wie bei jedem Hersteller: Eine komplett > unbegrenzte IDE kostet ein paar Tausend Dollars. Rowley Crossworks: $1500 kommerziell, $150 nichtkommerziell (kein Limit).
Fritz schrieb: > Welche 32-bit Architektur ist deiner Meinung nach dann nicht veraltet? Aus vergangenen Diskussionen würde ich mal drauf tippen, dass ihm die SuperH Familie von Renesas vorschwebt. Eine Architektur, die für Controller-Anwendungen gut konstruiert ist. Ich teile aber nicht den Eindruck, dass der Rest der Welt deshalb einpacken und heimgehen sollte, nur weil die SH-2A über umfangreiche Möglichkeiten der Einzelbitmanipulation im Speicher verfügen und mehrere Registerbanks existieren.
Ist der SuperH nicht eine steinalte load/store RISC Architektur? Bei Renesas sehe ich nur den RX mit Vorteilen gegenüber M0/M3. In Sachen RISC /CISC steht der RX allerdings auch nicht sooo gut dar wenn man sich mal die Benchmarkergebnisse von EEMBC ansieht. Der PIC32 übertrifft ihn sogar leicht.
Simon K. schrieb: > Ganz toll. Ansonsten das Gleiche wie bei jedem Hersteller: Eine komplett > unbegrenzte IDE kostet ein paar Tausend Dollars. CoCoox kostet nichts.
> CoCoox kostet nichts. und ist darüber hinaus extrem komfortabel und gespickt mit Beispielen. Es gibt sogar eine Funktion zum automatischen Generieren einer Filestruktur inklusive Möglichkeit per Klick entsprechende Peripherieelemente einzufügen. Ich habe bis heute nicht verstanden, warum offenbar so wenige Leute diese Software nutzen. Die komplette IDE ist in etwa 15 Minuten eingerichtet und nach einer halben Stunde blinkt die LED. Nichts mit stundenlanger Konfiguration oder so ;)
Stefan schrieb: > Bei Renesas sehe ich nur den RX mit Vorteilen gegenüber M0/M3. Mag sein, ich merke bloss immer wieder, dass MCUA gegen ARM stänkert und gewöhnlich irgendwelche Renesas aufgrund irgendwelcher Details der Implementierung in den Himmel lobt, ob nun SHx oder RX oder was auch immer. Oft mit zweifelhaften Argumenten - ich hoffe ja noch, dass er mal erklärt, was er oben mit seinen angeblichen I/O-Befehlen beim ARM meint oder weshalb ein Controller keinen I/O-Bereich im Adressraum haben sollte. Kein Controller taugt für alles. Manche sind beim Bitgepfriemel besser als ARM, darunter auch die "veralteten" Oldtimer der 51er-Klasse. Andererseits kann man mit einem einzigen Entwicklungssystem (Compiler/IDE) für ARM eine grosse Zahl verschiedener Controller verschiedener Hersteller abdecken. Und manchmal sind ARMs einfach kleiner und billiger (Renesas RX in SO20? Cortex-M0 wirkt da passender), oder auch viel schneller (Cortex-Ax, wer's braucht).
Jörg B. schrieb: > Simon K. schrieb: >> Ganz toll. Ansonsten das Gleiche wie bei jedem Hersteller: Eine komplett >> unbegrenzte IDE kostet ein paar Tausend Dollars. > > CoCoox kostet nichts. Ist aber auch keine IDE, die von einem Hersteller bereitgestellt wird und ist demnach nichts "offizielles". Aber ja, die ist echt nicht schlecht und unterstützt ganz schön viele Programmiergeräte. stm schrieb: > Es gibt sogar eine Funktion zum automatischen Generieren einer > Filestruktur inklusive Möglichkeit per Klick entsprechende > Peripherieelemente einzufügen. Hmm naja, ich halte da nicht so viel von. Mit dem Hinzufügen der Peripherieelemente meinst du sicher die STM StdPeriph Library, die ich jedoch nicht verwendete. Kann man eigentlich das Verwenden dieser Library in der IDE deaktivieren, oder funktioniert die nicht ohne?
stm schrieb: >> CoCoox kostet nichts. > > und ist darüber hinaus extrem komfortabel und gespickt mit Beispielen. > Es gibt sogar eine Funktion zum automatischen Generieren einer > Filestruktur inklusive Möglichkeit per Klick entsprechende > Peripherieelemente einzufügen. > > Ich habe bis heute nicht verstanden, warum offenbar so wenige Leute > diese Software nutzen. Das könnte daran liegen, dass die anderen Leute schon viele IDEs haben kommen und gehen sehen - viele sterben plötzlich, weil die Jungs keinen Bock mehr haben. Das ist nervig und bspw. für mich ein Grund, nicht mehr auf solche Nischen zu setzen. Eclipse ist da einfach "sicherer". Dazu kommt, dass ich eine IDE nicht nur für Mikrocontroller sondern auch andere Dinge (Tcl/Tk, PHP, usw.) einsetzen möchte. Und es ist natürlich unschön, dass es nur Win unterstützt. Auch das können andere besser. > Die komplette IDE ist in etwa 15 Minuten eingerichtet und nach einer > halben Stunde blinkt die LED. Nichts mit stundenlanger Konfiguration > oder so ;) Die Einrichtungszeit sollte bei der Wahl einer IDE sehr weit hinten stehen. Entscheidend ist, wie gut ich später damit zurecht komme. Da spielt es dann keine Rolle, ob ich 15 Minuten oder zwei Stunden benötige. Chris D.
Chris D. schrieb: > Das könnte daran liegen, dass die anderen Leute schon viele IDEs haben > kommen und gehen sehen - viele sterben plötzlich, weil die Jungs keinen > Bock mehr haben. Das war mein Argument oben mit "offizieller IDE" vom Hersteller. > Das ist nervig und bspw. für mich ein Grund, nicht mehr auf solche > Nischen zu setzen. Eclipse ist da einfach "sicherer". Auch wenn CooCox (und viele andere IDEs auf Eclipse basieren): Eben. Ein selbst hergerichtetes Eclipse kann man immer wieder neu herrichten, falls sich mal irgendeine Änderung ergibt. Bei 3rd Party IDEs ist man dann auf das Anpassen der IDE durch den Autor angewiesen.
ARM hatte damals (kurz nach der CPU-Steinzeit) irgentwie "keine Intension" etwas Neues zu bauen, deshalb hat man halt was Vorhandenes (Studienobjekt betr. minimalistischer CPU) genommen und abgekupfert, und das -mehr oder weniger- abgeändert. (Man muss wohl bezweifeln, ob sie überaupt einen 6800 oder 8051 kannten) Ja, ARM hat im OPcode weder sep IO-Befehle (wie bsp. 8085 oder AVR) noch sep Bit-Manipul-befehle auf Mem (wodurch man sich sep IO-Befehle sparen könnte wenn IO darin gemappt wäre), und hat schon gar nicht Befehle die generell auch mit (zumindest kleinem) Mem direkt rechnen können, weshalb nur LD/ST übrig bleibt, und es deshalb ein grässlicher Flaschenhals ist. (Man trinkt aufm Oktoberfest Bier aus Krügen, nicht aus Flaschen) (SH hat auch LD/ST-Architektur, mit ein paar Bit-Manipul-befehle auf Mem. Will man was Anderes auf Mem anwenden, muss man auch durch LD/ST durch. (egal ob Registerbänke oder nicht) RL78 ist aufgebohrter Z80.) (CPUs, die mit Mem direkt rechnen können (dadurch weniger Befehle (und meist auch weniger Takte) nötig) gibt es ja mehrere, dann mit (mehr oder weniger) anderen Macken.)
MCUA schrieb: > das -mehr oder weniger- abgeändert. (Man muss wohl bezweifeln, ob sie > überaupt einen 6800 oder 8051 kannten) ... die ultimativen Architekturen damaliger Zeit, verkannt oder sträflich missachtet von den Schöpfern der ARM Architektur. ;-) > irgentwie "keine Intension" etwas Neues zu bauen, ... und deshalb eine Art Architektur schufen, die keinen Vorgänger hatte, garnicht anders sein konnte als neu. RISCs fielen damals nicht grad vom Baum. John Cockes Erkenntnisse waren bei IBM nach wie vor Betriebsgeheimnis, nur Berkeley&Co boten eine ähnliche Entwicklung.
Die Zeit, in der ARM entstand, war eine Zeit, in der Architekturen wie VAX aktuell waren. Das war ein dominantes Vorbild vieler Designer, die Blüte der CISC-Ära, an die auch NatSemi mit der 32000 und NEC mit der V70 anknüpfen wollten. Motorola baute in die 68020 jenen Unsinn ein, den sie später aus Coldfire wieder ausbauten. Und Intel versuchte recht bald, die misratene iAPX 432 möglichst aus der Geschichte zu streichen. Damals in den 80ern entstanden parallel zu diesen hochkomplexen Designs ein paar einfachere, strukturell neue. Basierend auf der Erkenntnis mancher, dass diese Komplexität eher behindert als nützt. ARM war eines davon. Bei IBM hatte man immer noch Sorge, die eigenen Mainframes damit zu bekämpfen. DEC verhob sich im Laufe der 80er derart an der Weiterentwicklung der VAX, dass die Firma daran fast zugrunde ging. Während sich dann z.B. MIPS darauf konzentrierte, das mit den jeweiligen Möglichkeiten schnellste Design zu bauen, hatte Acorn/ARM eher vor, eine zeitgemässe für den Zweck ausreichende Leistung mit geringem Aufwand zu erreichen. Und entwickelte damit ganz nebenbei eine Architektur, die aufgrund ebendieser Einfachheit die erste oder eine der ersten 32-Bit Architekturen war, die sich problemlos als Core in Custom Chips einbauen liess. Als ich damals dem ARM2 Familie begegnete fiel mir das auch recht bald auf. Nämlich dass dieses Design, obzwar konzipiert als Kern für Acorn-Rechner, sich eher noch für leistungsfähige embedded Systems eignet, für die 8/16-Bitter zu klein und die anderen 32-Bitter zu gross und zu teuer sind. Natürlich hatte man damals Fehler gemacht. Das Interrupt-Design der ARMs (ausser den Cortex-Mx) ist Murks sobald man mehr als die zwei Prioritäten benötigt, und die dynamischen Shifts stehen wahlweise dem Registerfile oder der Pipeline im Weg.
A. K. schrieb: > Das Interrupt-Design der ARMs > (ausser den Cortex-Mx) ist Murks sobald man mehr als die zwei > Prioritäten benötigt, Das zeigt meines Erachtens, dass die Entwickler eher rechenintensive Anwendungen und keine leistungsfähigen Controller im Auge hatten. Die SH70xx hatten schon Anfang der 90er 15 Prioritätsebenen für Interrupts vorgesehen. A. K. schrieb: > (Renesas RX in SO20? Cortex-M0 wirkt da passender) Es gibt sicherlich eine Untergrenze für die Gehäusegröße, wo CPU+IO noch sinnvoll genutzt werden können. Einige Zeitgenossen sehnen sich sicherlich nach einem Cortex-M4 im 8-pol. DIP und sehen den LPC1114FN28 im schönen, breiten 28-pol. DIP als ersten Schritt in die richtige Richtung. Beitrag "LPC111xFD (Cortex-M0) jetzt auch in DIL28" (Ein Griff zum Herausziehen aus der Fassung wäre noch ganz nett :-) Ohne jetzt über Prozessorreligionen zu streiten, ein Dokument, wie Renesas selber ihre RX sehen. http://www.google.de/url?q=http://am.renesas.com/media/products/mpumcu/rx/rx200/Meet_the_RX200.pdf&sa=U&ei=0xBgUIXRJ-Wg4gTF5IHIAg&ved=0CCcQFjAG&usg=AFQjCNEzdKq3i8oZoZzNHA655DTRoU6Zmw
A. K. schrieb: > Das Interrupt-Design der ARMs > (ausser den Cortex-Mx) ist Murks Stimmt, dessen Entwickler müssen wohl richtig getrieft haben. Ich glaube nicht, daß es noch andere Architekturen gibt, wo man zwingend einen Spurious Interrupt Handler aufsetzen muß, damit es überhaupt funktioniert. Peter
m.n. schrieb: > Das zeigt meines Erachtens, dass die Entwickler eher rechenintensive > Anwendungen und keine leistungsfähigen Controller im Auge hatten. Klar. Das Ding war ja quasi als C64 für Anspruchsvolle gebaut worden. Die Nutzung als Controller ergab sich ungewollt.
Peter Dannegger schrieb: > Ich glaube nicht, daß es noch andere Architekturen gibt, wo man zwingend > einen Spurious Interrupt Handler aufsetzen muß, damit es überhaupt > funktioniert. Spurious Interrupts gibts anderswo auch. Bei PCs landen die dann technisch bedingt im niedrigst priorisierten IRQ7, dem für die Drucker-Schnittstelle. Jedenfalls früher beim ursprünglichen Interrupt-Controller, ob heute noch weiss ich nicht. Die gibts immer dann, wenn (1) die Auslösung von IRQs nicht gleichzeitig auch den Vektor definiert, sondern der erst mit dem Vektor-Zugriff festgelegt wird und (2) ein Device so gebaut ist, dass es sich nachträglich auch anders überlegen und einen IRQ-Request ggf. wieder zurückziehen kann (16C550 mit FIFO). ARM hatte keinen Interrupt-Controller vorgesehen und damit ist bei Verwendung eines separates Moduls (1) vorgegeben. Das eigentliche Problem auf das ich mich beziehe liegt aber woanders: Die Verwendung von R14 des IRQ-Kontextes für die Return-Adresse vom Interrupt. Weshalb der IRQ-Stack bei schachtelbaren Interrupts nicht als IRQ-Stack verwendet werden kann und man im Handler erst umständlich mit R14 und Register-Kontexten rumwurschteln muss. Ein MSR für die Exception-Return-Adresse, wie das viele andere RISCs machen, wäre sinnvoller gewesen.
MCUA schrieb: > weshalb > nur LD/ST übrig bleibt, und es deshalb ein grässlicher Flaschenhals ist. Der Hauptnachteil ist, daß dadurch fast nichts atomar gemacht werden kann und man ständig die Interrupts disablen muß. Man müßte einfach nur ein Bit im Befehlswort reservieren, das einen Befehl mit dem folgenden atomar macht. Damit könnten man bequem mehrere IO-Bits manipulieren oder mit Interrupts konsistente Daten austauschen. Statt der Clear-Register wäre das die weitaus bessere Lösung. Es fehlte den ARM-Entwicklern wohl die praktische Erfahrung. Peter
Peter Dannegger schrieb: > Man müßte einfach nur ein Bit im Befehlswort reservieren, das einen > Befehl mit dem folgenden atomar macht. Präfix-Befehl ist eleganter. Zilogs Z8encore hat sowas fest auf 3 Befehle fixiert und Microchips 16-Bitter PIC24&Co mit wählbarer Anzahl. Der Haken ist die dann eigentlich nötige Unterstützung durch den Compiler, also sowas wie atomic { ... } > Statt der Clear-Register wäre das die weitaus bessere Lösung. Es fehlte > den ARM-Entwicklern wohl die praktische Erfahrung. Einerseits dies. Es gab damals zwar Systeme mit deutlich höher entwickelter Interrupt-Kultur, aber ARM hatte ursprünglich ja auch keinen Controller im Auge. Allerdings hätte man das auch später hinzufügen können.
Ich habe mir nicht alle Beiträge durchgelesen, also verzeiht bitte wenn es schon erwähnt wurde oder am aktuell diskutierten Thema vorbei geht, ich nehme nur Bezug auf den Ausgangspost: Eine 'etwas' leistungsfähigere aber ebenso einfach zu handhabende Controllerfamilie sind die MSP430 von TI, das sind 16-bitter die vom 'feeling' den AVRs in der Entwicklung her sehr ähnlich sind und in der Anwendung auch bestimmt nicht komplizierter als die (8-bit) AVRs. Jeder der mit einer der beiden Controllerfamilien vertraut ist, sollte sich sehr schnell in die jeweils andere einarbeiten können. Für die MSPs gibt es, genau wie für die AVRs, eine GCC-Toolchain. Hardwaretechnisch benötigen sie auch keine kompliziertere Beschaltung als die AVRs - einzig zu beachten ist, dass sie mit max. 3.3V laufen, 5V ist bei den MSPs nicht. Allerdings benötigen sie auch nur diese eine Versorgungsspannung. Achso, und falls das relevant sein sollte: Bis auf einige wenige, sehr kleine - was die Ausstattung angeht, Vertreter der MSP430-Serie gibt es diese nur in SMD-Gehäusen. Weiterführende Lektüre und allgemein gute Infos im passenden Artikel: http://www.mikrocontroller.net/articles/MSP430 Was ansonsten natürlich auch eine leistungsfähigere Version der 'normalen' AVRs darstellt sind die neuen XMEGA-AVRs und wenn man noch mehr Performance benötigt gibt es da noch die AVR32-Serie - doch letztere stellen ähnliche Ansprüche an Entwickler und Hardware wie auch entsprechende Controller mit ARM-Architektur. Wenn es allgemein nur um einen Controller eben mit ARM-Architektur geht gibt es auch Derivate die in der Entwicklung sehr einfach handzuhaben sind; zu nenen sind da wohl an erster Stelle die LPC-Serie von NXP oder auch die STM32 von ST (mit letzteren habe ich allerdings keine Erfahrung und mit den zu vorletzt erwähnten auch nur begrenzte)
Ich komme aus der AVR Welt und arbeite jetzt seit Mai mit dem STM32F407 Discovery. Es gab große Umstiegsschmerzen, aber es hat sich gelohnt. Inzwischen arbeitet man mit dem Cortex-M4 genau so einfach und unkompliziert wie mit dem AVR. Die Entwicklungsumgebung CooCox ist free und steht dem AVR-Studio in nichts nach. Im Gegenteil, debuggen ist ein Genuss im Gegensatz zum AVR. Das Discovery F4 kostet 16.77€ und ist günstiger als jedes AVR Entwicklerboard. Zudem braucht man da keinen Programmer, weil das Discovery alles schon am Board hat. Ein USB Kabel, etwas PC Software und gut. Ich würde niemanden mehr empfehlen mit dem AVR zu beginnen. Der Cortex M4 ist wirklich genial!
Thomas Winkler schrieb: > Ich würde niemanden mehr empfehlen mit dem AVR zu beginnen. Der Cortex > M4 ist wirklich genial! Es hängt immer davon ab, was man überhaupt machen will. Z.B. ein Blinklicht würde ich doch lieber mit nem ATtiny13 machen. Oftmals will man ne kleine Steuerung aufbauen und hat keine Lust, extra für nur ein Stück ein Layout zu entwerfen und eine Platine zu fertigen. Dann schnell mal eine Uniplatine genommen den ATtiny draufgepappt, 5V angelegt und losgeproggt. Manchmal existiert nichtmal ein Schaltplan. Was an den einzelnen IO-Pins dranhängt, ist im h-File beschrieben. Einen LQFP176 oder UFBGA176+25 möchte ich nicht mehr löten. Peter
> irgentwie "keine Intension" etwas Neues zu bauen... Neu an sich war das StudienProjekt schon, aber Neu_und_Praxistauglich ist was anderes. >Die Zeit, in der ARM entstand, war eine Zeit, in der Architekturen wie >VAX aktuell waren. Das war ein dominantes Vorbild vieler Designer, die >Blüte der CISC-Ära... Ja, und ARM hatte das Gegenteil davon gemacht, Minimalistisch. Sowohl das eine als auch das andere Ende hat extreme Nachteile... ...und ist deshalb veraltet. Interrupt-Controller hat eigentlich nichts mit CPU zu tun, man kann ja alles anflanschen. Nur muss die CPU natürlich überhaupt INT-fähig sein und sollte nicht zu lange dafür benötigen. Auch das war bei ARM extrem schlecht. ---------------------------- Bit im OPcode für INT-enable wäre zwar besser als nichts und man könnte sich zwar separate Befehle für INT dis-en-able ersparen, jedoch so viele Befehle weniger wären das auch nicht, aber insbes. sollte INT disable ja garnicht gemacht werden, weil dadurch die INT-Latenz schon wieder viel zu lange wird. Viel besser wäre/ist doch ein leistungsfähigerer Befehlssatz, der auch Mem unterstützt, diese Befehle wären/sind dann auch automatisch atomic. Aber ARM kann (wegen dem minimalistischen Befehlssatz) da nichts machen, denn das wäre faktisch eine comlett neue Architektur.
Mal davon abgesehen daß die ARMs millionenfach eingesetzt werden und die Geräte erstaunlicherweise funktionieren hast du uns immer noch nicht verraten wer es deiner Meinung nach richtig macht.
> Das Discovery F4 kostet 16.77€ Etwas überteuert. Das Board bekommt man schon für 12 Euro :-) Allen weiteren Ausführungen kann ich nur beipflichten. Ich war vorher auch ein AVR-Fan, aber seit ich die STM32F1 und STM32F4 Reihe (und einige von TI) kenne, will ich die AVRs nicht mehr. Mittlerweile kostet das STM32F1Discovery Board nur noch 8 euro!! Wenn ich was auf Lochraster aufbauen will, pack ich da einfach das ganze Evalboard drauf und fertig. Selbst wenn es nur ein Blinklicht werden soll. Für 8 Euro spielt das doch keine Rolle mehr... Mittlerweile bietet Texas Instruments ein komplettes Evalboard mit einem CortexM4 für unter 5 Euro an!!! Das Board ist auch als Programmer nutzbar. Das ist doch eigentlich nicht mehr zu toppen ;) Für den Preis bekommt man nichtmal eine Lochrasterplatine + Tiny + Quarz. Es gibt wirklich keinen Grund mehr für mich einen AVR zu nehmen. Alleine die Leistung ist um Zehnerpotenzen größer :-)) Wenn sich ein großer AVR einen abrackert, schnarcht sich ein gleich teurer CortexM4 mit FPU und DMA doch einen ab. ^^
Simon K. schrieb: > Wenn ich "Monitorprogramm" schon höre, dann bekomme ich die Krise. Haben > damals in der Schule mit Z80s rumgefummelt, die sowas hatten. Ich redete von 1977-90. Da war noch keine Rede von AVRs oder so. State-of-the-Art war der 8048,6502,Z80 und eben der 8051. Und wenn man einen Monitor selber schreibt, macht das Spass und du lernst richtig was. Eines der genialsten Stückchen Software ist m.E. der in 2kByte geschriebene Monitor des Apple ][ von Steve Wozniak. Da können sich einige Programmierer mal ne Scheibe von abschneiden, die sowas nicht mal in 64 kByte hinkriegen.
hier mal ein interessanter Link: CortexM4-Board von Texas Instruments für 4,7 Euro: http://de.farnell.com/texas-instruments/ek-lm4f120xl/eval-stellaris-launchpad/dp/2192061 Noch Fragen? ^^
>hier mal ein interessanter Link: > >CortexM4-Board von Texas Instruments für 4,7 Euro: Finde ich nicht besonders interessant. STM32F4 Discovery kostet zwar vier mal so viel, bietet aber erheblich mehr Flash, RAM, Speed und Peripherie.
überschwenglicher_stm_fan schrieb: > hier mal ein interessanter Link: > > CortexM4-Board von Texas Instruments für 4,7 Euro: > > http://de.farnell.com/texas-instruments/ek-lm4f120... > > Noch Fragen? ^^ Ich finde es schon interessant. Weil es günstig ist werden es sich viele kaufen und TI wird es sicherlich auf Messen kostenlos verteilen. Dadurch wird es sicher bald viele nette kleine Anwendungen dafür geben.
> Finde ich nicht besonders interessant. > STM32F4 Discovery kostet zwar vier mal so viel, > bietet aber erheblich mehr Flash, RAM, Speed und Peripherie. Das stimmt schon. Ich habe selbst das STM32F4 Discovery (und bin total überzeugt davon), aber ich sehe das 4-Euro Board eher als Alternative für einen Attiny auf Lochrasterplatine. Denn man kann das Board ja einfach als Modul sehen, was man auf seine Lochrasteranwendungen drauf flanscht. Bei dem Preis kann man sich gleich ein paar auf Lager kaufen ^^
> eil es günstig ist werden es sich viele kaufen und TI wird es > sicherlich auf Messen kostenlos verteilen. TI ist da ziemlich schlau. Die machen es im Grunde wie ST. Eine bessere Werbung gibts eigentlich nicht, als den Markt mit billigen (oder auch kostenlosen) Boards und Samples zu überschwemmen. Bei den AVRs kosten die Programmer ja schon das Zigfache und repräsentieren obendrein eine überholte Technik. Für den Preis von 38 Euro für einen AVR- Programmer kann ich mir einen ST-Programmer für 1/4 des Preises nehmen. Trotzdem sind die AVRs natürlich ganz nett. Aber irgendwie für mich (auch im Hinblick auf Hobby-Basteleien) nicht mehr attraktiv. der STM nicht im DIP-Gehäuse? Egal! einfach das Disc. Board auf die Lochraster und fertig ^^ Für die paar Euro kaum der Rede wert.
Ja, stimmt schon. Habe mir vor kurzem auch ein F1 Discovery Board von STM geholt. Bisher immer nur mit AVRs herumgeschustert. Mittlerweile bin ich über die AVRs auch hinweg. Es gibt einfach zu viele Vorteile pro ARM in den Projekten, wo ich sie einsetze.
Mal eine Frage zu den STMs: Arbeitet man da, wie man es von den AVRs kennt, auf Registerebene mit dem Controller oder läuft alles über Libraries des Herstellers?
Sascha W. schrieb: > Mal eine Frage zu den STMs: > Arbeitet man da, wie man es von den AVRs kennt, auf Registerebene mit > dem Controller oder läuft alles über Libraries des Herstellers? Du kannst natürlich auch direkt auf Registerebene arbeiten (machen auch viele). Die vielen Defines in den Headerdateien der Library bilden diese nur auf Namen ab, unter denen sich man etwas vorstellen kann :-). Chris D.
Richtig. Ich habe mit den ST libraries angefangen, da ist alles schön überschtlich, verständlich und vorallem portabel (zwischen Cortex M0, M1, M3, M4, natürlich nur ST). Jetzt habe ich ein ziemlich zeitkritisches Projekt und mach es halt direkt mit den Registern. Man kann ja ganz einfach in die lib sourcen gucken und schauen welche Register verändert werden, wennman zu faul für das Datenblatt ist ... ;-) Die Initialisierung ist ja nicht zeitkritisch, daher mache ich die nach wie vor mit den ST libs
> Die Initialisierung ist ja nicht zeitkritisch, daher mache ich die nach > wie vor mit den ST libs Mache ich auch so. Die Libs sind meines Erachtens ganz gut organisiert. Grade die Vorgehensweise über Strukturen zu gehen finde ich gut. Bei zeitkritischen Sachen klicke ich einfach Rechtsklick auf die entsprechende Funktion und lasse mir den Inhalt anzeigen und kopier den direkten Registerzugriff und füge ihn direkt in meinen Code ein. Da wird wohl jeder seine Methoden haben... Alles in Allem bin ich grade bei der Initialisierung von Peripherie sehr von den Libs überzeugt. Da wird es im Grunde ein Kinderspiel USART, SPI,I2C usw anzusprechen. Das geht echt gut von der Hand. Ich finde es mittlerweile fast einfacher als bei einem AVR.
Also ich muss sagen, dass ich direkt von Anfang an ohne die StdPeriph Lib gearbeitet habe (ist ganz schön schwierig, bis man erstmal raus hat, wie man die aus dem Template Projekt "rausoperiert"). Sooo stark vereinfacht die Bibliothek das nun auch nicht. Zeilenmäßig wirds zumindest nicht wesentlich weniger im Programm. Ok, man muss vielleicht nicht mehr so viel ins Datenblatt herüberwechseln. Wie auch immer, kann sich ja zum Glück jeder selbst aussuchen ;-)
Ich habe gerade was zu einer vorkonfigurierten Eclipse Umgebung gefunden. http://forum.chibios.org/phpbb/viewtopic.php?f=13&t=557
Ich verwende CooCox für meinen F4. Bin sehr glücklich damit, und es braucht nicht mal 40 Minuten es in Betrieb zu nehmen ...
Schonmal jemand was mit den Nuvoton Cortex M0 gemacht? Ich hab hier ein NuTiny-SDK-120 rumliegen. Da ist ein Debugger mit dran, den kann man abbrechen. Der Core-Regler ist intern, d.h. man legt nur 2,5 .. 5,5V VDD an. Die Eingänge vertragen 5V und auch der ADC soll bis UREF = 5V arbeiten können. Im Reset sind die Ports wie beim 8051 weak high, man braucht also keine externen Pullups. Laut Manual werden die Ausgänge von VDD versorgt. Können die wirklich 5V liefern? Das wäre dann ja ein voll 5V fähiger 32Bitter, wow. Das Atomic-Problem fällt einem auch hier auf die Füße. Man hat SFRs für einen 16Bit-Port setzen oder nur einen Pin. Zusätzlich kann man auch ein Maske setzen, um Outputs zu schützen. D.h. ein Interrupt kann Pins ändern, und diese Änderungen kann man schützen, auch wenn der Interrupt gerade zwischen das Read-Modify-Write zuschlägt. Mit 128kB Flash und 16kB RAM ist er sehr üppig ausgestattet. Wie der Verbrauch im Vergleich zu einem 8051 ist, muß ich noch ermitteln. Die Hauptunterschiede des M0 zum M3 sind die fehlende Division und MPU. Also nichts von Bedeutung. Ich werde erstmal die 32kB Keil-Demo probieren. Peter
überschwenglicher_stm_fan schrieb: > hier mal ein interessanter Link: > > CortexM4-Board von Texas Instruments für 4,7 Euro: > > http://de.farnell.com/texas-instruments/ek-lm4f120... > > Noch Fragen? ^^ Ich habe mir davon welche geordert. Sehr ordentliche Boards. Schön klein, 2 User Taster und RGB LED USB . Kann von oben und oder unten was drauf gesteckt werden. Für das Geld kann man wohl nicht mehr bekommen zur Zeit finde ich!
Ich hab mir auch so TI Dinger (ek-lm4f120) besorgt. Da es Cortex-M4 sind, habe ich gehofft die sind so wie der STM32F407. Leider haben die kein SDIO und nur 80MHz. Trotzdem ist dieser Preis im Moment unschlagbar. Sicher kein Schaden wenn man davon ein paar auf Lager hat.
Thomas Winkler schrieb: > Ich verwende CooCox für meinen F4. Bin sehr glücklich damit, und es > braucht nicht mal 40 Minuten es in Betrieb zu nehmen ... Derart inspiriert habe ich es auch versucht. Mein inneres Timeout hat mich wieder davon abgebracht. "Build" funktioniert nicht. Ich soll eine gcc toolchain anwählen. Aber das Fenster "Select Toolchain Path", in dem diese Anwahl erfolgen soll, zeigt mir nicht an, was zu wählen wäre. Zu erahnen ist lediglich, daß das Fenster zu klein ist und nicht alles anzeigt. Ein beherzter Klick auf ok bringt nichts. Ich liebe solche Weichware.
CooCox ist eine IDE, Flashtool und Debugger UI. Dazu benötigt man eine Toolchain seiner Wahl, das ist bei CooCox nicht integriert. Und dann muss man natürlich auch sagen, wo diese Toolchain auf der Festplatte zu finden ist. Dafür ist es kostenlos und unbeschränkt. Ich würde auch mit IAR oder sonstwas arbeiten, aber die haben halt Preisvorstellungen, die für einen Hobbyisten wie mich astronomisch sind. Da lohnt es sich schon, dass man ein paar Dinge selbst installieren muss. :-D Jedenfalls kann man mit CooCox sehr gut arbeiten, wenn es erst mal richtig eingerichtet ist. Es ist schnell, komfortabel und schmiert nicht ab.
Thomas Winkler schrieb: > Und dann muss man natürlich auch sagen, wo diese Toolchain > auf der Festplatte zu finden ist. Das würde ich gerne tun, zumal ich zuvor, wie gewünscht, die vorgeschlagene GCC-ARM Version installiert habe. Nur, wenn mir diese geniale IDE die Fenster nicht so groß macht, daß deren Inhalt auch zu sehen ist, kann ich ihr garnichts sagen. Ist wohl doch eher etwas für Spezialisten. Nachdem jetzt von CooCox wiederholt meine Firewall getriggert wurde, schmeiß ich das Zeugs wieder in den Müll.
Ian schrieb: > Thomas Winkler schrieb: >> Ich verwende CooCox für meinen F4. Bin sehr glücklich damit, und es >> braucht nicht mal 40 Minuten es in Betrieb zu nehmen ... > > Derart inspiriert habe ich es auch versucht. Mein inneres Timeout hat > mich wieder davon abgebracht. > "Build" funktioniert nicht. Ich soll eine gcc toolchain anwählen. Aber > das Fenster "Select Toolchain Path", in dem diese Anwahl erfolgen soll, > zeigt mir nicht an, was zu wählen wäre. Zu erahnen ist lediglich, daß > das Fenster zu klein ist und nicht alles anzeigt. Ein beherzter Klick > auf ok bringt nichts. > > Ich liebe solche Weichware. Wer lesen kann ist klar im Vorteil. auf der Hauptseite der CoIDE ist ein link der es beschreibt. Download: Note: This version has not integrated GCC compiler. Before using CoIDE, you need to set GCC Toolchain first. Click here to see how to set. http://www.coocox.org/CoIDE/Compiler_Settings.html Wenn man denn gar nichts tun will sollte man es doch ganz lassen. Glaub mal nicht, dass du bei Keil ohne welche Einstellungen dein Programm in das Flash bekommst
Ian schrieb: > Nachdem jetzt von CooCox wiederholt meine Firewall getriggert wurde, > schmeiß ich das Zeugs wieder in den Müll. Naja, hinter CooCox steht ja eine Chinesische Uni (http://www.coocox.org/aboutus.htm). Ein Schelm, wer böses dabei denkt...
Ich muss auch sagen, dass Coocox bislang die am simpelsten einzurichtende IDE war die ich je nutzte. Nach 15 Minuten läuft eigentlich immer alles. Hab die Software jetzt schon auf 5 Rechnern eingerichtet und nie größere Probleme gehabt.
Peter Dannegger schrieb: > Ich hab hier ein NuTiny-SDK-120 rumliegen. Da ist ein Debugger mit dran, > den kann man abbrechen. Uhm, im Sinne von 'kannste knicken'? :-P Oder ist da eine Sollbruchstelle im Board und du kannst den Debug Port entfernen? Ich hab hier den VL Discovery mit der letzten unbeschränkten Vollversion von Atollic TS. Ich ärgere mich zwar mittlerweile, das ich nicht gleich den STM32F4 Discovery gekauft hab, aber alles in allem ist das schon schön schon - installieren, Manual lesen und losprogrammieren ging innerhalb eines Nachmittags. Das Atollic keine HEX files für den Programmierer erzeugen wollte war ärgerlich, aber einfach zu lösen.
Angehängte Dateien:
-
Toolchainselect.JPG
150 KB
Ian schrieb: > Nur, wenn mir diese geniale IDE die Fenster nicht so groß macht, daß > deren Inhalt auch zu sehen ist, kann ich ihr garnichts sagen. > Ist wohl doch eher etwas für Spezialisten. Wie bei jedem neuen Tool muss man sich auch mit CooCox auseinandersetzen, um es zu begreifen. Diese Zeit habe ich geopfert und nun bin ich davon vollends begeistert. Das besagte Fenster ist - wie in der Anlage - trotz meiner leichten Kurzsichtigkeit klar zu sehen.
Matthias Sch. schrieb: > Oder ist da eine > Sollbruchstelle im Board und du kannst den Debug Port entfernen? Ja. Auf beiden Seiten sind dann 10-pol. Steckverbinder vorgesehen. http://www.nuvoton.com/hq/enu/ProductAndSales/ProductLines/IndustrialIC/ARMMicrocontroller/ARMCortexTMM0/PublishingImages/NuTiny-SDK-NUC120.jpg Peter
>Das wäre dann ja ein voll 5V fähiger 32Bitter, wow. Gibts mehrere. >Die Hauptunterschiede des M0 zum M3 sind die fehlende Division und MPU. >Also nichts von Bedeutung. Beim M0 sind weniger Register benutzbar und Speicherzugriffe müssen ausgerichtet sein!
MCUA schrieb: > Beim M0 sind weniger Register benutzbar und Speicherzugriffe müssen > ausgerichtet sein! @MCUA Sorry, aber was ist mit Speicherzugriffe müssen ausgerichtet sein gemeint? Geht es dabei nur darum das jede Byte Variable nun ein doppel Word (bei 32-Bit Architektur) belegt? Ist der Speicher dann eigentlich noch Byteweise adressierbar? Wäre ja Verschwendung? Geht es dann hauptsächlich um einen Speicerverlust bei Datentypen kleiner größe? Oder gibt es da andere Nachteile z.B. den geringeren Datendurchsatz wenn nur eine Byte Variable dann statt z.B. 4 geladen werden. Bin noch nie darauf gestoßen ... aber bei AVR 8-Bit und ARM Cortex3 scheint das ja auch nicht vorhanden zu sein. Finde hier einige Beiträge sehr interessant zu den Prozessorarchitekturen und möchte allen für die Beiträg danken. Auch wenn ein großteil wohl besser zu einer Diskussion des http://www.mikrocontroller.net/articles/Mikrocontroller_Vergleich Artikels passen würde ;)
Habe gerade zu meiner Frage auf: http://www.mikrocontroller.net/articles/Digitaltechnik Alignment auf größeren Prozessoren ganz unten gefunden, denke da ist alles gesagt? Hätte ja auch mal früher beim suchen klappen können ...
Der Unwissende schrieb: > Sorry, aber was ist mit Speicherzugriffe müssen ausgerichtet sein > gemeint? Nicht ausgerichtet sind Wortzugriffe auf Daten, deren Adresse nicht durch 4 teilbar ist. Meist ist diese Einschränkung von minderer Bedeutung, insbesondere wenn man kein Ethernet verwendet. > Geht es dabei nur darum das jede Byte Variable nun ein doppel Word (bei > 32-Bit Architektur) belegt? Tut sie nicht. > Ist der Speicher dann eigentlich noch > Byteweise adressierbar? Ja.
@die Wissenden :) Also geht es darum, dass dann kein Datentyp über 2 Felder liegen sollte, z.B. bei 32 Bit ein long auf Adresse 2-5 liegt, da dann ersteinmal 0-3 geladen werden müsste und danach 4-7 um daraus den Datentyp zusammenzubasteln? Das sollte dann doch auch nicht nur bei den schon genannten ethernet headern auftreten, sondern auch wenn alle Optimierungen ausgeschaltet sind bei ungünstiger Reihenfolge der Variablendeklaration? Also: char a; long b; char c; ??? oder wird dann padding eingesetzt, was dann wiederum den Speicherverbrauch belasten würde ... oder ist das einfach compiler abhängig?
Der Unwissende schrieb: > Also geht es darum, dass dann kein Datentyp über 2 Felder liegen sollte, > z.B. bei 32 Bit ein long auf Adresse 2-5 liegt, da dann ersteinmal 0-3 > geladen werden müsste und danach 4-7 um daraus den Datentyp > zusammenzubasteln? Yep. Das ist selten vorteilhaft, weil es selbst bei Architekturen, die damit umgehen können, stets langsamer ist als korrekt justiert. High-Performance Implementierungen wie x86 kommen besonders schlecht damit zurecht. > Das sollte dann doch auch nicht nur bei den schon genannten ethernet > headern auftreten, sondern auch wenn alle Optimierungen ausgeschaltet > sind bei ungünstiger Reihenfolge der Variablendeklaration? Nein, weil kein Compiler sie so packen wird, wie du das dir vorstellst. Er wird ggf. Löcher lassen um das zu vermeiden. Es sei denn du verlangst es ausdrücklich über irgendeine Spracherweiterung.
Peter Dannegger schrieb: > Das wäre dann ja ein voll 5V fähiger 32Bitter, wow. > > Das Atomic-Problem fällt einem auch hier auf die Füße. Der oben erwähnte RX210 ist ebenfalls ein voll 1,6 - 5,5V 32Bitter, weshalb er sich (auch) als AVR-Ersatz anbietet. Das ARMe Atomic-Problem hat er jedoch nicht: BSET, BCLR, ... werden von Ints nicht unterbrochen. Und wenn man auf hohe Codedichte Wert legt, es gibt auch Befehle mit 1 Byte Länge. Das sind zum Beispiel kurze Verzweigungen oder auch NOP oder RTS. Die ARMs (M3/M4) sind schnell mit 1,25 DMIPS/MHz, wobei die mir vorliegenden Zahlen dem M0 nur 0,9 DMIPS/MHz zubilligen. Die RX sind mit 1,56 DMIPS/MHz schneller. Wenn man mit 128kB Code auskommen kann, bekommt man für die RXe ein vollständiges HEW (Editor/Compiler/Debugger), kostenlos, was HIER ja absolut notwendig ist :-) Die Demoversionen von KEIL und IAR sind insofern blöde, da man kein Ass-Listing zu sehen bekommt. Gerade zur Abschätzung des erzeugten Codes ist dies unbedingt notwendig. Natürlich sind die STM32F4 schöne Teile, wenn es aber um Controlleraufgaben geht, bleiben bei mir die RX auf Platz 1.
m.n. schrieb: > Die ARMs (M3/M4) sind schnell mit 1,25 DMIPS/MHz, wobei die mir > vorliegenden Zahlen dem M0 nur 0,9 DMIPS/MHz zubilligen. > Die RX sind mit 1,56 DMIPS/MHz schneller. Aber nur auf den MHz gesehen. RX210 max 50 MHz =78 Mips F4 168 MHz =210 Mips.
Jörg B. schrieb: > Aber nur auf den MHz gesehen. RX210 max 50 MHz =78 Mips F4 168 MHz > =210 Mips. Der RX210 ist mit der kleinste der RXe. RX62/RX63 laufen mit 100MHz. Wenn Du absolute Zahlen vergleichen willst, dann vergleiche bitte auch die absoluten Preise von RX210 und STM32F4.
Bei Future. RX210 100 Pin 64 KB Ram 512KB Flash 6,59€ STM32F4 100 Pin 194 KB Ram 512 KB Flash 6,78€ Für 3 mal soviel Ram und mehr als 2 fachen Durchsatz bin ich dann gerne bereit 19 Cent mehr zu zahlen. ;)
Jörg B. schrieb: > Für 3 mal soviel Ram und mehr als 2 fachen Durchsatz bin ich dann gerne > bereit 19 Cent mehr zu zahlen. ;) Damit Du den F4 mit 5V betreiben kannst schaltest Du wohl zwei in Reihe? Das verdoppelt schon mal den Preis :-) Für 3V Anwendungen kann man den RX621 o.ä. nehmen. Der macht dann 156 DMIPS bei 100MHz und braucht keine zusätzliche Interrupt-Blockaden für atomare Befehlsabarbeitung. Wenn man mehr RAM braucht, schließt man ein ext. SDRAM an. Jetzt sag bloß noch, der F4 würde ext. SDRAM unterstützen? Über Religionen läßt sich eben vortrefflich streiten. Das ist der Hauptgrund, warum sich die Menschen weltweit ohne Unterlass die Köpfe einschlagen - jeden Tag neu in den Nachrichten :-)
Ich bin ja nicht damit angefangen zu vergleichen... Wollte nur deine Aussage, dass der RX210 schneller wäre im Vergleich zum F4, nicht so stehen lassen. Warum sollte der F4 keinen externen Ram unterstützen? Ab 144 Pin tut er es. Und die 3,3 V machen ja wohl den Kohl nicht Fett ;) So genug gesülzt, schönen Abend noch...
Wer 5V braucht ist sicher gut bedient mit dem RX210. Aber wieso steht hier jeder auf 5V? Moderne Technik läuft doch sowieso eher mit 3,3V (SD Karten, CPLD, FPGA etc.). Gut wenn man mit Retro Zeugs rum macht (6502, Z80, TTL) sind die 5V praktisch. Aber auch die 3,3V Controller sind da einsetzbar mit etwas Beschaltung.
m.n. schrieb: > Natürlich sind die STM32F4 schöne Teile, wenn es aber um > Controlleraufgaben geht, bleiben bei mir die RX auf Platz 1. Dank der agressiven Werbung von ARM und der vielen Anbieter, sehe ich leider keine Chance, einen anderen MC durchzusetzen. Den Flaschenhals, daß alles aus 3 Befehlen besteht (Load, Operation, Store) und damit nichts atomar ist, kann man einem Laien nur schwer verklickern. Damit die Zuweisungen nicht zu kryptisch werden, werde ich wohl erstmal einige atomare Macros schreiben müssen. Das Gewürge mit den Set- und Clear-Registern will ich auf keinen Fall im Quelltext sehen, das muß irgendwie versteckt werden. Vielleicht hat ja schon jemand sowas gemacht. Peter
>Der RX210 ist mit der kleinste der RXe. es gibt kleinere. >Den Flaschenhals, daß alles aus 3 Befehlen besteht (Load, Operation, >Store) und damit nichts atomar ist, kann man einem Laien nur schwer >verklickern. Die Wait-States wohl auch nicht. Der schnellste STM32 läuft WorstCase dank Gurken-Flash nur mit ca 25MHz. Der schnellste RX (nä. Jahr) mit 200MHz. Ist das jetzt 8 x schneller? Nein eher 8..20x schneller, wegen effizienterem OP-Code. RX geht mom. bis 2MB Flash. DMIPS-Angaben sind nur statistischer Kram, der zudem noch für RISC optimiert wurde. Man muss sich für einen Vergleich schon den konkreten Befehlssatz, f, Takte usw anguggen. >Das ARMe Atomic-Problem hat er jedoch nicht: BSET, BCLR, ... werden von >Ints nicht unterbrochen. BMCnd , ADD/FADD dsp16[Rs],Rd , MOV(B,W,L) dsp16[Rs],dsp16[Rd] , auch nicht
Peter Dannegger schrieb: > Dank der agressiven Werbung von ARM und der vielen Anbieter, sehe ich > leider keine Chance, einen anderen MC durchzusetzen. Na ja, ist halt so. Der F4 ist affenschnell! > Den Flaschenhals, daß alles aus 3 Befehlen besteht (Load, Operation, > Store) und damit nichts atomar ist, kann man einem Laien nur schwer > verklickern. Aber diese (Laien) werden es sein, die hier dann anfragen: "Mein Programm läuft eigentlich gut, aber 2-3 mal am Tag bleibt es stehen. Warum?". :-) Der NUC120 ist ja auch nicht schlecht. Allerdings finde ich vier Interrupt-Prioritäten nicht mehr zeitgemäß. Bei so vielen IO-Geschichten sollte eine feinere Abstufung möglich sein. Leider habe ich dazu kein vollständiges Datenblatt gefunden. Mich würde interessieren, ob dieser NUC120 auch ein so 'beschränktes' DMA wie der F4 hat. Beim F4 läßt sich nämlich anhand der SRC, DEST und CNT Register nicht erkennen, wieviel schon abgearbeitet wurde. Die zeigen immer die Startwerte an. Diese Feinheiten zeigen sich erst, wenn man richtige Anwendungen hat und nicht nur mit Demoboards herumspielt. Thomas Winkler schrieb: > Aber wieso steht > hier jeder auf 5V? Moderne Technik läuft doch sowieso eher mit 3,3V (SD > Karten, CPLD, FPGA etc.). Es ist nicht unbedingt die Nostalgie. 5V Technik ist zwar langsamer aber auch störunanfälliger. Wenn ich lineare Inkrementalgeber einsetze, so laufen diese in der Regel mit 5V mit einigen zig-mA. MOSFETs direkt anzusteuern, ist mit 5V-Pegeln einfacher. Bei einer stromsparenden Anwendung mit LiPo-Akku kann dieser direkt den µC versorgen. Die ca. 4,2V Ladespannung werden problemlos verkraftet; ein 3V-Design muß da passen. Zusätzliche Spannungsregler verbrauchen Energie und 'Kohle'. Es kommt eben immer darauf an, was man machen will/muß.
MCUA schrieb: >>Der RX210 ist mit der kleinste der RXe. > es gibt kleinere. Das war auch meine Aussage. > Der schnellste STM32 läuft WorstCase dank Gurken-Flash nur mit ca 25MHz. Aber in der Praxis ist das eher WürstchenKäse. Alles in allem ist er, wie gesagt, affenschnell :-)
Matthias Sch. schrieb: > Ich hab hier den VL Discovery mit der letzten unbeschränkten Vollversion > von Atollic TS. Ich ärgere mich zwar mittlerweile, das ich nicht gleich > den STM32F4 Discovery gekauft hab, Matze, soll ich die Bestellung des STM32F4DISCOVERY jetzt doch besser bleiben lassen? Ich werde da nach Lesen der Threads allmählich diffuser. Wollte den eigentlich morgen bestellen. Es sollte nur mit Tools funktionieren, die ich nicht kaufen muß. Sonst trete ich das wieder in die Tonne.
>> Der schnellste STM32 läuft WorstCase dank Gurken-Flash nur mit ca 25MHz. >Aber in der Praxis ist das eher WürstchenKäse. Alles in allem ist er, >wie gesagt, affenschnell :-) Ja, wenn man tolerieren kann/darf, dass ein Affe die 1-Mio-EU-teure CNC-Maschine gegen die Wand fährt.
MCUA schrieb: >>> Der schnellste STM32 läuft WorstCase dank Gurken-Flash nur mit ca 25MHz. >>Aber in der Praxis ist das eher WürstchenKäse. Alles in allem ist er, >>wie gesagt, affenschnell :-) > Ja, wenn man tolerieren kann/darf, dass ein Affe die 1-Mio-EU-teure > CNC-Maschine gegen die Wand fährt. Dann hat der Affe schlecht programmiert :-)
>Matze, soll ich die Bestellung des STM32F4DISCOVERY jetzt doch besser >bleiben lassen? Ich werde da nach Lesen der Threads allmählich diffuser. Diffuser in welcher Richtung? Wenn du bisher nur AVR programmiert hast bläst dir ein STM32F4 mal frische Luft durchs Hirn. Der wird sich mit allem langweilen was du ihm anzubieten hast.
>>>> Der schnellste STM32 läuft WorstCase dank Gurken-Flash nur mit ca 25MHz. >>>Aber in der Praxis ist das eher WürstchenKäse. Alles in allem ist er, >>>wie gesagt, affenschnell :-) >> Ja, wenn man tolerieren kann/darf, dass ein Affe die 1-Mio-EU-teure >> CNC-Maschine gegen die Wand fährt. >Dann hat der Affe schlecht programmiert :-) Oder den Jitter nicht beachtet.
MCUA schrieb: >>>>> Der schnellste STM32 läuft WorstCase dank Gurken-Flash nur mit ca 25MHz. >>>>Aber in der Praxis ist das eher WürstchenKäse. Alles in allem ist er, >>>>wie gesagt, affenschnell :-) >>> Ja, wenn man tolerieren kann/darf, dass ein Affe die 1-Mio-EU-teure >>> CNC-Maschine gegen die Wand fährt. >>Dann hat der Affe schlecht programmiert :-) > Oder den Jitter nicht beachtet. Was dasselbe ist. Wilhelm Ferkes schrieb: > Matze, soll ich die Bestellung des STM32F4DISCOVERY jetzt doch besser > bleiben lassen? Ich werde da nach Lesen der Threads allmählich diffuser. > > Wollte den eigentlich morgen bestellen. Es sollte nur mit Tools > funktionieren, die ich nicht kaufen muß. Sonst trete ich das wieder in > die Tonne. Lass Dich mal nicht verrückt machen. Das ist eine solide Familie, die gerade mit dem F4 eine Menge an Möglichkeiten bietet. Die "schlimmen" Einschränkungen sind eigentlich keine, wenn man sich halbwegs geschickt anstellt. Gerade mit dem STM32 hab ich bisher gelernt, dass man 99% der zeitkritischen Dinge von Timern und DMA erledigen lassen kann, ohne den Kern in irgendeiner Weise zu belasten. Interrupts brauche ich fast gar nicht mehr (im Gegensatz zum AVR bspw.) Wichtig ist: Schritt für Schritt einarbeiten - sonst wirst Du erschlagen :-) Chris D.
Ich denke das atomic-Problem wird deutlich überbewertet. Wenn man einen M4 auch nur ein bisschen ausreizen will in Punkto Flash, dann hat man soviel Code an der Backe, dass das bei vielen für 2 Leben reicht wenn es selbst geschrieben ist. Das meiste besteht dann aus Libs. TcpIp Stack, Softwarecodec u.s.w. Alles ziemlich High-Level. Die Softwareteile wo das atomic-Problem eine Rolle spielt sind dagegen mehr als vernachlässigbar. Da kann man damit leben. Und für viele Sachen sind die SET und CLR Register besser als das verodern oder verunden. Normaler Zugriff auf int ist auch unalignt atomic bei den Cortexen. 5V an den Eingängen können auch viele M3 schon ab. >Ja, wenn man tolerieren kann/darf, dass ein Affe die 1-Mio-EU-teure >CNC-Maschine gegen die Wand fährt. Sich auf die paar Eigenheiten der Controller einzustellen ist nun wirklich nicht so schwer. Immer noch besser als PSTR-Orgie beim avr.
>>Ja, wenn man tolerieren kann/darf, dass ein Affe die 1-Mio-EU-teure >>CNC-Maschine gegen die Wand fährt. >Sich auf die paar Eigenheiten der Controller einzustellen ist nun >wirklich nicht so schwer. Klar, brauchst für harte Echtzeit-Fähigkeit ja 'nur' den ganzen betreffenden Code auf unlineare ASM-Befehle hin abzuklopfen
MCUA schrieb: > Klar, brauchst für harte Echtzeit-Fähigkeit ja 'nur' den ganzen > betreffenden Code auf unlineare ASM-Befehle hin abzuklopfen Wo fangen bei dir harte Echtzeit-Fähigkeiten an? Taktgenaues Timing von Pingewackel ist am extremen Ende davon und meistens keine Forderung. Harte Echtzeit-Bedingungen lassen sich quantifizieren und das muss man dann auch in jedem Einzelfall tun. Und folglich in jedem Einzelfall entscheiden, welche Lösung die sinnvollere ist. Wer jeden allerkleinsten Jitter vermeiden muss, der ist in dieser Controller-Klasse falsch und mit CPLDs/FPGAs besser dran (oder beispielsweise XMOS). Was sind eigentlich nichtlineare Befehle? Wenn du damit alle Befehle meinst, deren Laufzeit nicht unverrückbar z.B. 2 Takte beträgt: Je höher die Leistungsfähigkeit einer CPU oder eines Controllers, desto variabler werden die Befehle. Allein DMA verhagelt schon die exakte Reproduzierbarkeit.
Peter Dannegger schrieb: > Das Gewürge mit den Set- und Clear-Registern will ich auf keinen Fall im > Quelltext sehen, das muß irgendwie versteckt werden. Gegen saubere Modularisierung und Layering der Software sprich ja nun wirklich nichts. Wer bei nichttrivialen Programmen explizites Pingewackel quer durch den ganzen Quelltext streut, der hat meist etwas falsch gemacht. Ich kann allerdings diese Verteufelung solcher Register nicht so recht nachvollziehen. Klar, es kann ungewohnt sein. Aber es kann auch Möglichkeiten bieten, für die man per Befehlssatz schon hochkomplexe Bitfeld-Befehle benötigen würde. Wenn man mehrere Bits eines Ports, aber nicht alle, gleichzeitig auf einen beliebigen Wert setzen will.
A. K. schrieb: > Was sind eigentlich nichtlineare Befehle? Wenn du damit alle Befehle > meinst, deren Laufzeit nicht unverrückbar z.B. 2 Takte beträgt: Je höher > die Leistungsfähigkeit einer CPU oder eines Controllers, desto variabler > werden die Befehle. PS: So trifft das ebenfalls auf Renesas RX zu.
A. K. schrieb: > MCUA schrieb: >> Klar, brauchst für harte Echtzeit-Fähigkeit ja 'nur' den ganzen >> betreffenden Code auf unlineare ASM-Befehle hin abzuklopfen Harte Echtzeitfähigkeit heisst erstmal nur, dass etwas definitiv innerhalb einer gewissen Zeitspanne reagieren muss - mehr nicht. > Wo fangen bei dir harte Echtzeit-Fähigkeiten an? Taktgenaues Timing von > Pingewackel ist am extremen Ende davon und meistens keine Forderung. So sehe ich das auch. Wenn ich es taktgenau und schnell benötige, dann wird das bspw. über Timer erledigt. > Harte Echtzeit-Bedingungen lassen sich quantifizieren und das muss man > dann auch in jedem Einzelfall tun. Und folglich in jedem Einzelfall > entscheiden, welche Lösung die sinnvollere ist. Wer jeden allerkleinsten > Jitter vermeiden muss, der ist in dieser Controller-Klasse falsch und > mit CPLDs/FPGAs besser dran (oder beispielsweise XMOS). Genau so sehe ich das auch. Und gerade bei 1 Mio. teuren Maschinen kommt es auf die paar Euro wirklich nicht an. Da wird man kaum einen Controller einsetzen, der so hart an seiner Leistungsgrenze eingesetzt wird, dass man die Befehle einzeln aussortieren muss. Dann nimmt man einen FPGA und jemanden, der sich damit auskennt (ich nicht) aber sicher keinen Controller, den man totoptimieren muss. Schon die Arbeitszeit, die man dort reinsteckt, macht das sonst unwirtschaftlich. > Was sind eigentlich nichtlineare Befehle? Wenn du damit alle Befehle > meinst, deren Laufzeit nicht unverrückbar z.B. 2 Takte beträgt: Je höher > die Leistungsfähigkeit einer CPU oder eines Controllers, desto variabler > werden die Befehle. Allein DMA verhagelt schon die exakte > Reproduzierbarkeit. Und in 99% der Fälle ist die auch nicht nötig. Wenn sie nötig ist, gibt es bessere Lösungen (Timer, FPGA, etc.) Chris D.
Lass dir das F4 Discovery nicht vermiesen! Der STM32F4 ist einfach nur genial. Wenn man aus der AVR Welt kommt, eröffnet sich mit dem F4 eine völlig neue, faszinierende Welt!
Thomas Winkler schrieb: > völlig neue, faszinierende Welt Na mag schon sein, wenn es aber darum geht schnellstmöglich zur optimalen Produktlösung zu kommen sollte man sich nicht vom schönen Preis/Leistungsverhältnis der ARM-Hardware Sand in die Augen streuen lassen! Mit im Paket sind hier ein deutlich erhöhter Aufwand in und für die Softwareentwicklung. Wo es leistungsmäßig erforderlich ist mag dieser unumgänglich sein, nur zu oft aber tut es auch ein 8-Bitter. Verliebtheit in schnelle,leistungsfähige Hardware ist wenig zielführend, ebenso wie erweiterte und flexible, aber letztlich ungenutzte Konfigurationsmöglichkeiten die Entwicklung eher komplizierter machen.
> PS: So trifft das ebenfalls auf Renesas RX zu. Wenn der RX so toll wäre, wäre Renesas nicht kurz vor der Insolvenz: http://www.ftd.de/unternehmen/industrie/autoindustrie/:autoelektronik-toyota-konsortium-soll-renesas-retten/70094252.html > Na mag schon sein, wenn es aber darum geht schnellstmöglich zur > optimalen Produktlösung zu kommen sollte man sich nicht vom schönen > Preis/Leistungsverhältnis der ARM-Hardware Sand in die Augen streuen > lassen! Mit im Paket sind hier ein deutlich erhöhter Aufwand in und für > die Softwareentwicklung. Wo es leistungsmäßig erforderlich ist mag > dieser unumgänglich sein, nur zu oft aber tut es auch ein 8-Bitter. > Verliebtheit in schnelle,leistungsfähige Hardware ist wenig zielführend, > ebenso wie erweiterte und flexible, aber letztlich ungenutzte > Konfigurationsmöglichkeiten die Entwicklung eher komplizierter machen. Die ARM-Programmierung ist auch für Einsteiger nicht schwieriger als AVR. Schwierig wird es natürlich bei grossen ARMs mit viel Peripherie. Für den Einsteiger empfiehlt sich daher ein kleiner ARM, z.B. LPC1114, den gibt es sogar als DIP fürs Steckbrett: Beitrag "DIP-ARM Samples von Arrow" Aber auch beim F4 Discovery kommt man durch die vielen Beispiele gut rein.
Richtig, und das discovery passt auch auf das Steckbrett oder Lochraster. Sicher, wenn man vom AVR umsteigt auf den ARM muss man zeit investieren. Das ist wohl bei jedem Plattformwechsel so. Aber ich wage jetzt zu behaupten: sobald man sich die Grundbasis an Code geschaffen hat, ist man mit dem F4 Discovery genauso schnell wie mit dem AVR. Das gilt natürlich auch für den Renesas oder diesem TI Cortex-M4. Ich würde jedenfalls nicht mehr auf AVR zurückgehen. Selbst wenn es nur eine blinkende LED sein soll, seit es dieses 5€ Board von TI gibt.
Peter Dannegger schrieb: > Den Flaschenhals, daß alles aus 3 Befehlen besteht (Load, Operation, > Store) und damit nichts atomar ist, kann man einem Laien nur schwer > verklickern. Der Anfänger sollte sich auch erst mal besser mit 8051, PIC, AVR o.ä. amüsieren, bis er kein völliger Laie mehr ist. Besser sogar noch mit einem 8085 oder 8048. ;-) Ich besitze noch das Buch von Günter Schmitt zum 8085. Das ist zwar schon 30 Jahre alt, aber er als Professor schlägt einfache µC und µP zum Einstieg vor. Man fängt ja auch klein an, nicht groß. Na ja, die Dinge bei modernen µC sind halt etwas komplexer als beim Standard-8051, aber man kann damit umgehen. Ich selbst hatte so einen Brassel mit einer Variablen in den LPC2000 mal. Kein Voll-Laie mehr, ahnt man aber, was so alles passiert. Und man bekommt es auch selbst heraus. Wenn man sie an zwei Stellen verwendet, kann es passieren, daß auf einmal mitten im Lesevorgang ein anderer Wert drin steht. Dann muß man sie halt atomarisieren. ;-) Oder die Handler für Spurious- und Surprise-Interrupt, Nesting Interrupts, oder Interface zwischen Assembler und C einmal im THUMB-Mode und einmal im ARM-Mode. Oder Assembler-Befehle zählen, um die Laufzeit zu ermitteln. ;-) Wenn man das aber alles ein mal weiß, ist es gut. Chris D. schrieb: > Wilhelm Ferkes schrieb: >> Matze, soll ich die Bestellung des STM32F4DISCOVERY jetzt doch besser >> bleiben lassen? Ich werde da nach Lesen der Threads allmählich diffuser. >> Wollte den eigentlich morgen bestellen. Es sollte nur mit Tools >> funktionieren, die ich nicht kaufen muß. Sonst trete ich das wieder in >> die Tonne. > Lass Dich mal nicht verrückt machen. Das ist eine solide Familie, die > gerade mit dem F4 eine Menge an Möglichkeiten bietet. Grundsätzlich interessiert er mich nach wie vor. Muß nur noch mal die Bestellung absenden. ARM an sich kenne ich noch von den LPC2000. Dort mußte ich mich ja auch mal ganz alleine einarbeiten. > Die "schlimmen" Einschränkungen sind eigentlich keine, wenn man sich > halbwegs geschickt anstellt. Das denke ich auch so. > Gerade mit dem STM32 hab ich bisher gelernt, dass man 99% der > zeitkritischen Dinge von Timern und DMA erledigen lassen kann, ohne den > Kern in irgendeiner Weise zu belasten. Interrupts brauche ich fast gar > nicht mehr (im Gegensatz zum AVR bspw.) Oha, sowas ist mir neu. Wie kommt man ohne Interrupts aus? Wenigstens Timer betreibt man doch nur im Interrupt. Kannst du das näher erläutern? Die LPC2000 waren gegenüber dem 8051 schon affenartig schnell, so daß wir damals sogar auf die meiste Interruptpriorisierung verzichten konnten, und alle Interrupts gleich priorisiert als IRQ anordneten. Wir brauchten für eine präzise Zeitmessung nur eine einzelne höhere Priorisierung, den FIQ. Das reichte. Haben die Cortex-M4 eigentlich auch noch diese ARM- und THUMB-Modes mit Umschaltung und gemischter Verwendung im Code, wie im LPC2000? > Wichtig ist: Schritt für Schritt einarbeiten - sonst wirst Du erschlagen > > :-) Ach was, vor dem µC habe ich keine Panik, ganz im Gegenteil. Ich freue mich mal auf was moderneres. Eher werde ich Kopfschmerzen bekommen, eine Toolchain vollständig und problemlos ans Laufen zu bekommen. Bzw. erst mal die richtigen Komponenten zusammen suchen. Es gibt ja hier bereits einen älteren Thread, wenn man in der Forensuche nach dem Board sucht. Den SDCC mit Geany als Oberfläche und Batch-Files bekam ich immer noch hin. Und Debugging auf meine eigene alte Art. Bei den Discovery-Boards wird ja sicher nicht viel im Lieferumfang dabei sein, nicht mal das Mini-USB-Kabel. Bei dem Preis habe ich dafür aber auch vollstes Verständnis. > Chris D. Willem
klopp die AVRs in die Tonne ;-) Sicherlich ist der Umstieg zunächst mal ein gewisser Aufwand. Aber ich kann aus Erfahrung sagen, dass man sich mit einem stm32F4 genauso schnell etwas aufbauen kann wie mit einem AVR. Die Bibliotheken sind umfangreich und gut dokumentiert und es gibt massig Beispiele im Netz (oder bei freien IDEs wie Coocox schon per Klick integrierbar. --> da blinkt die LED schneller als man sich einen Tee kochen kann). Man sollte einfach den Kopf frei machen von der Angst vor der Komplexität. Einfach mal GPIOs ansprechen und LED blinken lassen. Dann hat man verstanden wie man die Peripherie mit der vorhandenen Bib. konfiguriert und die anderen Sachen wie USART, ADC usw geht dann flux von der Hand. Und wenn man einmal alles angesprochen hat gehen die nächsten Projekte super schnell.
Wilhelm Ferkes schrieb: > Haben die Cortex-M4 eigentlich auch noch diese ARM- und THUMB-Modes mit > Umschaltung und gemischter Verwendung im Code, wie im LPC2000? Nein. Nur Thumb. Bei M0 nur Thumb, bei M3 und M4 als Thumb-2, was viele Möglichkeiten von ARM zu Thumb hinzufügt und damit den Performance-Nachteil aufhebt.
wutz schrieb: > da blinkt die LED schneller als man sich einen Tee kochen kann Den Trick mußt du mir jetzt aber mal verraten, wie man in geringfügig mehr als 250ms einen Tee kocht. ;-) Vielleicht einen Mikro-Tee aus der Mikro-Küche. > klopp die AVRs in die Tonne ;-) Aach! Nicht doch! Ich werde meine 8051-er auch nicht in die Tonne kloppen. Vielleicht sind sie mal ein Hilfsmittel, um mit den größeren Controllern zusammen zu arbeiten. Z.B. über UART gekoppelt, wenn ich auf dem 8051-Board schon was interessantes habe. Beispiel: Eines meiner 8051-Boards hat den ollen Keyboard-Display-Controller 8279 mit Tastatur-Matrix und 30 Tasten, der den µC voll entlastet, und dem µC eine schon fertig entprellte Taste sogar mit N-Key-Rollover sendet, wenn man das so programmiert. Ein anderes 8051-Board hat 2x40 Zeichen LCD, und DCF77, was über RS232 auch ausgegeben wird. RS232 haben sowieso alle. Manche auch LWL am UART. Oder die alten µC alleine. Für kleine Aufgaben. Wenn ich mich nicht ganz täusche, ist sogar der olle 8085 aktuell der meist produzierte µP bei Intel. Das hat Gründe. Und es gibt auch noch 4-bit-µC. A. K. schrieb: > Nein. Nur Thumb. Bei M0 nur Thumb, bei M3 und M4 als Thumb-2, was viele > Möglichkeiten von ARM zu Thumb hinzufügt. Was bedeutet das jetzt konkret für mich? Keinen 32-bit-Code?
Wilhelm Ferkes schrieb: > Was bedeutet das jetzt konkret für mich? Keinen 32-bit-Code? Thumb ist 32-Bit Code, codiert in 16 Bit breiten Befehlen. In Thumb-2 dürfen sie wieder etwas länger sein, d.h. einige sind in 32 Bits codiert. Beipielsweise 3-Adress Operationen mit integriertem Shift und die Möglichkeit, in 2 Befehlen eine 32-Bit Konstante zu laden. Auch die bedingte Ausführung, ein Alleinstellungsmerkmal der ARM Architektur, ist wieder da. Aber diesmal nicht als Teil jedes Befehls, sondern codierungmässig günstiger als Präfix, der die Bedingungen von bis zu 4 Folgebefehlen definiert.
A. K. schrieb: > Thumb ist 32-Bit Code, codiert in 16 Bit breiten Befehlen. Etwas kastriert allerdings. Der Code wird aus dem Programmspeicher auf jeden Fall in 16 bit geholt, nicht in 32 bit. ARM und THUMB hatten doch im ARM7TDMI-S einen Grund, oder? ARM-Code direkt in 32 bit geholt ist etwas schneller, und THUMB spart etwas Codelänge? Aber seis drum. Mit THUMB kann man sicher auch auskommen.
man sollte bei den alten ARM7 chips nicht übersehen das das flash damals meist extern war und nur mit 16 bit angebunden war. da macht dann thumb schon wieder sinn. statt 2 speicherzugriffe nur noch einen.
Wilhelm Ferkes schrieb: > ARM und THUMB hatten doch im ARM7TDMI-S einen Grund, oder? ARM-Code > direkt in 32 bit geholt ist etwas schneller, und THUMB spart etwas > Codelänge? Richtig. Und Thumb-2 ist die Synthese aus beidem. Performance wie ARM, Länge wie Thumb. Wenn man ARMs Benchmarks ernst nimmt, dann sogar schneller als ARM, weil nach Jahren der Divisionsabstinenz ARM plötzlich festgestellt hat, wie wichtig die nur in Thumb-2 existierenden Divisionoperationen sind. Und die deshalb viel häufiger als früher in den Benchmarks auftauchen. ;-)
123 schrieb: > man sollte bei den alten ARM7 chips nicht übersehen das das flash damals > meist extern war und nur mit 16 bit angebunden war. Nicht bei bspw. LPC2129 oder LPC2138. Die hatten ausreichend Flash, daß man oft kein externes brauchte.
ARM7TDMI wurde 1994 definiert, da war interner Flash-Speicher noch nicht sonderlich verbreitet. Es gibt allerdings ARM7TDMI Implementierungen, deren Flash-Bandbreite für nativen ARM Code nicht ausrecht (Analog Devices, Atmel). Bei den LPC2000 war das kein Problem.
A. K. schrieb: > Performance wie ARM, > Länge wie Thumb. Wenn man ARMs Benchmarks ernst nimmt, dann sogar > schneller als ARM, Ich kenne es noch anders. Das ist aber schon 5 Jahre her, quasi Mittelalter. Thumb erreichte (jetzt grob geschätzt) z.B. um die 70-80% Speed gegenüber ARM, dafür brauchte THUMB nur 70-80% Codespeicher gegenüber ARM. Der THUMB-Mode war in den LPC2000 hauptsächlich deswegen drin, falls man im ARM-Mode mit dem integrierten Flash nicht ganz aus kommt, und nicht so zeitkritischen Code flashsparend in THUMB machen konnte.
Wilhelm Ferkes schrieb: > Ich kenne es noch anders. Das ist aber schon 5 Jahre her, quasi > Mittelalter. Thumb erreichte (jetzt grob geschätzt) z.B. um die 70-80% > Speed gegenüber ARM, dafür brauchte THUMB nur 70-80% Codespeicher > gegenüber ARM. Das bezieht sich auf Thumb, ich mich aber auf Thumb-2.
Wilhelm Ferkes schrieb: > Der Anfänger sollte sich auch erst mal besser mit 8051, PIC, AVR o.ä. > amüsieren, bis er kein völliger Laie mehr ist. Wenn man bei Nuviton (ehem. Winbond) nachschaut, wird man erstaunt feststellen, daß die nicht nur Cortex M0, sondern auch neue 8051-er im Programm haben. Angefangen vom 12T Klassiker über 6T (Philips), 4T (Dallas) bis zum schnellen 1T (Atmel). Es muß also noch ein bedeutender Markt für die 8051-er existieren. Peter
Peter Dannegger schrieb: > Es muß also noch ein bedeutender Markt für die 8051-er existieren. Der 8051, schon 25 Jahre tot gewünscht, lebt! Und ich bereue deswegen nicht, daß ich mal mit dem Ur-8051 begann. Die ganzen interessanten SiLabs-Derivate, habe noch ein Board. Das sollte ich auch mal auspacken.
Wilhelm Ferkes schrieb: > Matze, soll ich die Bestellung des STM32F4DISCOVERY jetzt doch besser > bleiben lassen? Ich werde da nach Lesen der Threads allmählich diffuser. Nee, nee, das ist schon das richtige. Die VL Dicovery haben den STM32F103RB, und der ist im Vergleich zu einem XMega nicht wirklich der Bringer, es gab sie halt um die Ecke hier bei Segor, und den STM32F4 Discovery nicht. Dieser ist deutlich schneller und hat die neuere Architektur, und kostet nur ein paar Mäuse mehr. Es lohnt sich also, den STM32F4 Discovery zu holen und nicht den VL Discovery (ValueLine). Mit der Toolchain ist das so eine Sache. Ich hatte vor ein paar Monaten noch die Atollic Jungs genommen, weil da alles fertig konfiguriert war und sie keine Codebeschränkung hatten. Nun wollen sie Geld und sind nicht besser als die anderen. Demnächst muss ich also mal mit CooCox oder Eclipse auseinandersetzen, wobei Eclipse wohl die eierlegende Wollmilchsau ist und verschiedenste Architekturen und Prozessoren unterstützt. Die Konfiguration dauert aber - Internet und eine Menge Zeit wird man wohl brauchen. Coocox muss ich mir mal anschauen, davon hab ich null Ahnung.
Matthias Sch. schrieb: > Nun wollen sie Geld und sind > nicht besser als die anderen. Genau das ist es ja, meine Fragen. Nicht, daß ich bei der Toolchain auf einem Rest von 10% sitzen bleibe, und das streng limitiert ist. Oder einen Teil davon gar nicht bekomme. Ich muß ja mit den berühmten 374 Euronen Lebensunterhalt im Monat rund kommen, du weißt sicher, was ich meine. ;-) Aber sonst: Danke für deine Anmerkungen.
MCUA schrieb: > Der schnellste STM32 läuft WorstCase dank Gurken-Flash nur mit ca 25MHz. > Der schnellste RX (nä. Jahr) mit 200MHz. Ist das jetzt 8 x schneller? > Nein eher 8..20x schneller, wegen effizienterem OP-Code. Das ist natürlich kompletter Unsinn. Würde man auf PCs deine Interpretationskünste anwenden, dann wären sie heute kaum schneller als vor 20 Jahren. Weil demzufolge jeder Befehl 100 oder 200 Takte benötigen würde. Richtig ist nur, dass die Pipeline der RX CPUs effizienter ist als die sehr simple Pipeline der ARM7/Cortex-M Cores.
A. K. schrieb: > Richtig ist nur, dass die Pipeline der RX CPUs effizienter ist als die > sehr simple Pipeline der ARM7/Cortex-M Cores. Wegen des schmalen Cores sind die ARM auch energiesparsam. Manch einer zieht das ernsthaft als Kriterium heran, ich einst auch mal.
Wilhelm Ferkes schrieb: > Wegen des schmalen Cores sind die ARM auch energiesparsam. Manch einer > zieht das ernsthaft als Kriterium heran, ich einst auch mal. Da wirds etwas komplizierter. Ein kleiner Core frisst weniger Strom. Die Frage ist dann, ob man mit einem pro Takt schnelleren Core bei deshalb niedrigerem benötigten Takt mehr oder weniger Strom benötigt. Und die RX sind unstrittig pro Takt schneller als die Cortex-M. Die Antwort auf diese Frage hängt nicht zuletzt mit dem verwendeten Herstellungsprozess und dessen Designrules zusammen. Beispiel: Nvidias Tegra 3 hat sichtbar 4 Cores, technisch aber 5. Einer davon ist mit low-power Designrules gebaut, mit entsprechend niedriger Taktgrenze, die anderen sind auf Performance optimiert. Ist wenig los, dann wird auf den low-power Core gewechselt und den anderen 4 wird der Strom gekappt. Ohne diesen low-power Core wäre es möglicherweise sinnvoller, den Job schneller abzuarbeiten um sich früher wieder schlafen legen zu können (Intels Empfehlung für Atom). Der krasseste Fall war Intels Pentium 4. Dessen Designrules waren so sehr auf Performance getrimmt, dass er aufgrund der Leckströme auch völlig ohne Takt schon eine aktive Kühlung benötigte.
Wilhelm Ferkes schrieb: > Chris D. schrieb: >> Gerade mit dem STM32 hab ich bisher gelernt, dass man 99% der >> zeitkritischen Dinge von Timern und DMA erledigen lassen kann, ohne den >> Kern in irgendeiner Weise zu belasten. Interrupts brauche ich fast gar >> nicht mehr (im Gegensatz zum AVR bspw.) > > Oha, sowas ist mir neu. Wie kommt man ohne Interrupts aus? Wenigstens > Timer betreibt man doch nur im Interrupt. Kannst du das näher erläutern? Prinzipiell hat man natürlich dieselben Möglichkeiten wie bei den AVRs, aber z.B. durch DMA noch deutlich mehr. Ein Beispiel, welches ich im Moment teste (ich arbeite mich ja selbst noch ein :-) Zwei Audiosignale werden per externem ADC mit je 16 Bit gewandelt und per I2S an den STM32F4 geschickt. Gleichzeitig erzeuge ich per Timer einen 100ns-Takt, der zwei DMA-Kanäle "befeuert". Der erste Kanal liest die gewandelten Werte und speichert sie in je einem Ringpuffer. Der zweite Kanal liest an anderer Stelle im Puffer die Daten wieder aus und schiebt diese in die internen DACs (die allerdings nur mit 12 Bit wandeln). Je nach "Abstand" der schreibenden und lesendenn DMA-Zeiger ergibt sich dann eine entsprechende Verzögerung und zwar mit 100ns Auflösung. Das alles funktioniert nach Initialisierung der Module (I2S, DMA, DAC) ohne ein Programm im Hintergrund. Der STM32F4 dreht also quasi Daumen ;-) So kann man im STM32F4 intern viele "Strippen ziehen": wenn ein Text per ausgegeben werden soll, lässt man den UART einfach nach Ende der Zeichenübertragung an die DMA senden, dass sie gefälligst das nächste schicken soll. Diese macht das und der UART sendet vollautomatisch das nächste Zeichen. Das alles geht komplett ohne Interrupts - und erheblich schneller: wie gesagt: der obige Ringpuffer wird mit 10MHz befüllt und gelesen! Chris D. @A.K.: Sehr interessant, Deine Einlassungen zu den Architekturen - lese ich immer gerne und mit großem Interesse. Ich spreche sicher auch für andere: Bitte mehr :-)
Chris D. schrieb: > Zwei Audiosignale werden per externem ADC mit je 16 Bit gewandelt und > per I2S an den STM32F4 geschickt. Gleichzeitig erzeuge ich per Timer > einen 100ns-Takt, der zwei DMA-Kanäle "befeuert". Es gibt ja so manche Audiophile, aber mir war bisher noch keiner begegnet, der deswegen Audiodaten mit 10MHz abtastet. Selbst bei Fledermäusen wär das noch eine Grössenordnung zu schnell. :-)
> Zwei Audiosignale werden per externem ADC mit je 16 Bit gewandelt und > per I2S an den STM32F4 geschickt. Gleichzeitig erzeuge ich per Timer > einen 100ns-Takt, der zwei DMA-Kanäle "befeuert". Der erste Kanal liest > die gewandelten Werte und speichert sie in je einem Ringpuffer. Der > zweite Kanal liest an anderer Stelle im Puffer die Daten wieder aus und > schiebt diese in die internen DACs (die allerdings nur mit 12 Bit > wandeln). Je nach "Abstand" der schreibenden und lesendenn DMA-Zeiger > ergibt sich dann eine entsprechende Verzögerung und zwar mit 100ns > Auflösung. Hallo Chris! Ich interessiere mich auch sehr für die Möglichkeiten des STM32F4 und habe auch schon einige Sachen mit dem Discovery Board getestet. Die DMA- Geschichte interessiert mich besonders. Habe ich das richtig verstanden, dass in deinem Beispiel der Timer einen DMA-Request erzeugt und dann der DMA entsprechend im Takt dieser Requests mit inkrementerendem Zeiger auf ein Array zugreift im Circular mode? Ich habe neulich überlegt ob es möglich wäre einen GPIO-Port per DMA zu setzen. Allerdings konnte ich im Datenblatt im entsprechenden Request-Mapping keinen GPIO-Port finden. Ich wollte eine Sequenz auf dem GPIO-Port erzeugen (habe auch einen Thread im Forum hinterlassen, aber da hat sich keiner gemeldet :-) ). Wenn das ginge wäre das natürlich genial. Damit könnte man diverse schöne Dinge machen, ohne das die CPU einen Finger rühren muss.
DMA-Anfänger schrieb: > Ich habe neulich überlegt ob es möglich wäre einen GPIO-Port per DMA zu > setzen. Allerdings konnte ich im Datenblatt im entsprechenden > Request-Mapping keinen GPIO-Port finden. Der DMA-Kanal wird nicht auf den Port sondern auf den Timer gemappt. Weil es dabei um die Auslösung geht. Worauf der Kanal dann konkret zugreift, das ist per Adresse frei wählbar, darf also auch ein Port sein.
> Der DMA-Kanal wird ja auch mit dem Timer assoziiert, nicht mit dem Port. > Weil es bei dieser Assoziierung um die Auslösung geht. Worauf der Kanal > dann konkret zugreift, das ist per Adresse frei wählbar. Das darf also > auch ein Port sein. Das bedeutet für eine Sequenz auf einem GPIO-Port müsste ich lediglich durch einen Timer Requests auslösen (Channel + Stream entsprechend der Request-Mapping-Tabelle auf Timer konfigurieren) woraufhin dann mittels DMA auf ein Array mit Werten (für die Sequenz) zugegriffen wird und als Ziel (DMA_PeripheralBaseAddr) dann die Baseadresse des BSRR angegeben wird?
Fast korrekt. Du musst schon die exakte Registeradresse angeben, nicht die Basisadresse vom GPIO Registerblock. Also beispielsweise die Adresse vom BSRR. MCUA wird das aber bestimmt nicht imponieren, denn auch DMA ist nicht gänzlich frei von Jitter. ;-)
A. K. schrieb: > Fast korrekt. Musst schon die exakte Portadresse angeben, nicht die > Basisadresse. Ja genau - so habe ich es auch gemeint :-) Klingt ziemlich genial das Ganze. Im Grunde kann man so ja wirklich nahezu beliebig Daten zwischen Peripherie und Memory herumschieben ohne CPU-Belastung. Das ist wirklich interessant. Wenn man zum Beispiel WAV-Dateien abspielen will, geht das komplett ohne CPU-Last. Zu Chris Beispiel mit dem Ringpuffer fällt mir spontan ein Echo-Effekt ein. Man könnte die Daten per DMA einlesen und dann verzögert und schrittweise leiser wiedergeben. Dabei muss die CPU fast nichts machen. Interessant wäre überhaupt die Nutzung als Effektgerät.
> MCUA wird das aber bestimmt nicht imponieren, denn auch DMA ist nicht > gänzlich frei von Jitter. ;-) Kannst du das noch ein wenig näher erläutern? Danke!
DMA-Anfänger schrieb: >> MCUA wird das aber bestimmt nicht imponieren, denn auch DMA ist nicht >> gänzlich frei von Jitter. ;-) > > Kannst du das noch ein wenig näher erläutern? Die Zeit zwischen Ablauf des Timers, also Auslösung des DMA-Kanals, und dem Zugriff des Kanals auf das Portregister ist nicht notwendigerweise konstant. Je nachdem was zu dem Zeitpunkt der Auslösung grad auf dem Bus passiert kann es sich paar Takte verzögern.
Chris D. schrieb: > Wie auch immer. Hauptsache, Du unternimmst etwas. > > Dann schreibst Du ein schönes Tutorium über den STM32, wie man mit dem > GDB debuggen kann, mit guten Beispielen, erklärst die Takterzeugung, wie > man die für Timer berechnet, wie DMA funktioniert usw. und baust Dir > daraus eine ordentliche Homepage. > > Dann schreibst Du Abstraktionsbibliotheken z.B. für Grafikerzeugung und > setzt Dich vielleicht mit einem RTOS auf dem STM32 auseinander. > > Dazu dann noch "Wilhelms Programmschnipsel", wo jede Woche irgendeine > einfache pfiffige Routine angeboten wird. > > Irgend so etwas eben. > > Und ruckzuck hast Du reichlich Leser, die mit Fragen kommen und Hilfe > benötigen. Und da sind dann auch schnell mal Firmen dabei. > > Du wärst nicht der erste, der so zu Projekten und Arbeit kommt. Ich melde mich jetzt schon als potentieller Leser an ;-) Habe mir eben das STM32F4DISCOVERY bestellt und möchte da versuchen damit klar zu kommen. Es wird sicher holprig werden der Weg, aber machbar ist es auf jedenfall.
> Die Zeit zwischen Ablauf des Timers, also Auslösung des DMA-Kanals, und > dem Zugriff des Kanals auf das Portregister ist nicht notwendigerweise > konstant. Je nachdem was zu dem Zeitpunkt der Auslösung grad auf dem Bus > passiert kann es sich paar Takte verzögern. hmm... Wie sieht das aus, wenn ich nur einen Kanal eines Streams aktiviere? Dann kommen mir für den entsprechenden Stream ja keine Requests von anderen Kanälen in die Quere. Wie ich eben gesehen habe gibt es ja auch noch Möglichkeiten die DMA-Priorität zu verändern (es gibt 4 Stufen von low bis very high). Ich kann jetzt grade aber nicht abschätzen wie stark der Jittereffekt schlimmstenfalls wird. Müsste man sich wohl mal in der Praxis angucken.
> Dank der agressiven Werbung von ARM und der vielen Anbieter, sehe ich > leider keine Chance, einen anderen MC durchzusetzen. Warum ist dann beim Halbleiter-Ranking oben kein ARM-Hersteller? >Wer jeden allerkleinsten >Jitter vermeiden muss, der ist in dieser Controller-Klasse falsch und >mit CPLDs/FPGAs besser dran (oder beispielsweise XMOS). Nein. Man verwendet keine CPLDs/FPGAs (auch nicht für ne teure CNC-Maschine), wenn man nicht muss. Und manche Controller sind halt besser als andere. "Controller-Klasse" ist nicht definiert. >Je höher die Leistungsfähigkeit einer CPU oder eines Controllers, desto >variabler werden die Befehle. Achso, je besser desto besser. Das ist keine Aussage. Und ARM kann selbst mit kleinen Mem-bereichen NICHTMAL rechnen, geschweige denn bei "besseren" CPUs "besser" rechnen. >> Der schnellste STM32 läuft WorstCase dank Gurken-Flash nur mit ca 25MHz. >> Der schnellste RX (nä. Jahr) mit 200MHz. Ist das jetzt 8 x schneller? >> Nein eher 8..20x schneller, wegen effizienterem OP-Code. >Das ist natürlich kompletter Unsinn. Totaler Quatsch. Bei Hard-Realtime sinds 25MHz. Da kannst du reden (und hoffen) wie du willst. (oder musst extremen Aufwand betreiben). Also was sind 200/25? >Würde man auf PCs deine Interpretationskünste anwenden, dann wären >sie heute kaum schneller als vor 20 Jahren. Humbug zum Quadrat. Die etlichen Nachteile von ARM habe ja schon genannt. Da kannst DU INTERPRETIEREN, wie du willst. (Vergleich mit PCs ist Blödsinn, weil etliche Parameter ganz anders sind) >Weil demzufolge jeder Befehl 100 oder 200 Takte benötigen Quatsch. hab ich nie behauptet. >Richtig ist nur, dass die Pipeline der RX CPUs effizienter ist als die >sehr simple Pipeline der ARM7/Cortex-M Cores. Quatsch. OP-Code ist besser, Pipeline ist besser, Flash ist besser, Periferie ist besser, UB-Bereich ist besser. Anders gesagt (bei Ausführung ausm Flash), RX kann all das das, was (der olle) ARM kann, und vieles mehr. So, jetzt kannst du interpretieren.
DMA-Anfänger schrieb: > hmm... Wie sieht das aus, wenn ich nur einen Kanal eines Streams > aktiviere? Dann kommen mir für den entsprechenden Stream ja keine > Requests von anderen Kanälen in die Quere. Die nicht, aber möglicherweise die CPU. Wenn die in der Zeit nicht pennt, sondern langsame Peripheriebusse beansprucht. Der DMA-Kanal muss warten bis der laufende Buszyklus beendet ist. > abschätzen wie stark der Jittereffekt schlimmstenfalls wird. Müsste man > sich wohl mal in der Praxis angucken. Müsste man auch ohne Scope mit dem Gerät selbst messen können. Programmier einen DMA-Kanal auf einen mit vollem Takt laufenden Timer und lese damit den Timer-Wert aus.
A. K. schrieb: > Chris D. schrieb: >> Zwei Audiosignale werden per externem ADC mit je 16 Bit gewandelt und >> per I2S an den STM32F4 geschickt. Gleichzeitig erzeuge ich per Timer >> einen 100ns-Takt, der zwei DMA-Kanäle "befeuert". > > Es gibt ja so manche Audiophile, aber mir war bisher noch keiner > begegnet, der deswegen Audiodaten mit 10MHz abtastet. Selbst bei > Fledermäusen wär das noch eine Grössenordnung zu schnell. :-) Oh, das war wohl missverständlich :-) Die Audioabtastung erfolgt mit 96kHz, nur das Schreiben in den Ringpuffer mit 10MHz. Es sind also durchaus mehrere gleiche Werte im Puffer. Aber nur so erreiche ich eine Granulierung von 100ns bei der Signalverzögerung. Chris D.
MCUA schrieb: >>Je höher die Leistungsfähigkeit einer CPU oder eines Controllers, desto >>variabler werden die Befehle. > Achso, je besser desto besser. Das ist keine Aussage. Die Aussage war: Leistungssteigernde Massnahmen in CPUs reduzieren die Kalkulierbarkeit der Laufzeit einzelner Befehle. Die Laufzeit lässt sich also nicht mehr allein durch einen Blick ins Manual bestimmen. Und davon ist bereits RX betroffen, stärker als ein im RAM laufender ARM7. Weshalb? Wie gross ist die worst case Laufzeit von sowas wie ADD R1,R2? Laut Manual 1 Takt kann sie aber auch 2 Takte betragen. Das liegt an der anderen Pipeline, bei ARM7 und Cortex-M tritt dieser Effekt nicht auf. > Bei Hard-Realtime sinds 25MHz. Deine fragwürdige Ansicht zu "Hard-Realtime" wurde oben schon behandelt. Die völlig falsche Rechnung mit 200/25 wird durch Wiederholung nicht besser. Waitstates - auf die du offenbar raus willst - bremsen den Fetch bei sequentiellem Code wenig bis überhaupt nicht, da beispielsweise ein Prefetch in Verbindung mit (hoffentlich ausreichender) Flash-Bandbreite das ausbügelt. Hauptsächlich nichtsequentieller Befehlsfluss ist davon betroffen, sowie Datenzugriff auf Flash. Auf deine 25MHz käme man aber nur, wenn jeder einzelne Befehl davon betroffen wäre, was nie der Fall sein kann. Nicht einmal im worst case. Übrigens behauptet diesen Unfug nicht einmal Renesas. Immerhin werben die mit einem Wert um die 1,6 DMIPS/MHz gegenüber den 1,25 von Cortex-M3, nicht von 10 DMIPS/MHz. Zwar gilt der ARM-Wert nur ohne Waitstates, aber das hat nicht annähernd die Märchendimension, die du hier zeichnest.
MCUA schrieb: >>Weil demzufolge jeder Befehl 100 oder 200 Takte benötigen > Quatsch. hab ich nie behauptet. Das war eine Extrapolation aus deiner Ansicht, dass für "Hard-Realtime" als Laufzeit einer Befehlssequenz unbedingt die maximal mögliche Laufzeit jedes einzeln betrachteten Befehls ohne Berücksichtigung vom Kontext addiert werden muss. Anders kommt man nämlich nicht auf deine 25MHz. Nur ist das nicht zulässig. Nicht bei PC-Prozessoren und nicht bei ARMs. Weder im Normalfall, noch im worst case. > OP-Code ist besser, Der Befehlssatz ist reicher und performanter, das Codierungsschema kann in Fragen der Performance eine Rolle spielen, aber der Opcode ist ziemlich schnuppe.
>Deine fragwürdige Ansicht zu "Hard-Realtime" wurde oben schon behandelt. Hard-Realtime heisst nichts weiter, als dass innerhalb einer bestimmten max-Zeit eine Sache erledigt sein muss. fragwürdig ist da gar nichts. Und mache CPUs sind da halt besser, manche schlechter geeignet. >Die völlig falsche Rechnung mit 200/25 wird durch Wiederholung nicht >besser. Deine undefinierte, falsche Aussage wird durch Wiederholung auch nicht besser. >Waitstates - auf die du offenbar raus willst - bremsen den Fetch >bei sequentiellem Code wenig bis überhaupt nicht, da der Prefetch das >ausbügelt. Hauptsächlich nichtsequentieller Befehlsfluss ist davon >betroffen, sowie Datenzugriff auf Flash. Auf deine 25MHz käme man aber >nur, wenn jeder einzelne Befehl davon betroffen wäre, was nie der Fall >sein kann. Nicht einmal im worst case. HAHA. Deshalb sinds ja gerade worst case 25MHz. Denn du weisst überaupt nicht WIEVIELE sequentielle Befehle aufeinander folgen. All das Zeugs ist nichts als Vermutung und Hoffnung. Wenn du nicht extreme Anstrengungen hinsichtl der ASM.Befehle machst, bleiben worstcase 25MHz, alles andere ist Wunschdenken. (Der F4-Accel. brauch 4 Flash-Takte um Fuss zu fassen, und wenn danach wieder kein seq. Code da ist gehts von vorne los, und gurgt vor sich hin) >Übrigens behauptet diesen Unfug nicht einmal Renesas. Blödsinn. DMIPS ist, wie schon gesagt, nur irgenteine Variante von vielen. Renesas erwähnt das halt, weil andere es auch machen. Es kommt aber immer auf den konkreten Fall an, nicht auf irgent ein Statistik-Gequake. Und natürlich gibt es Fälle, bei denen dieser Faktor auch auftaucht. Und ein ARM Benchmark der ausm RAM läuft ist eine Lachnummer, hat mit Realität extrem wenig bis nichts zu tun, weil schlichtweg nicht alles reinpasst. (bzw kann man nur einen extrem kleinen Codteil darauf anwenden). Und zu >RX kann all das das, was (der olle) ARM kann, und vieles mehr. kannst du (ausser Hoffnung) definitv nichts entgegen setzen.
MCUA schrieb: > Und mache CPUs sind da halt besser, manche schlechter geeignet. Und weshalb sollte mich jeder einzelne Takt stören, wen die geforderte Zeitbedingung beispielsweise im Millisekundenbereich liegt? > Denn du weisst überaupt nicht WIEVIELE sequentielle Befehle aufeinander > folgen. Nein? Bei einer IBM650 wirds kompliziert, aber nicht so bei ARMs. Wann sind hintereinander stehende und nacheinander ablaufende Befehle bei den Cortex-M nichtsequentiell? > (Der F4-Accel. brauch 4 Flash-Takte um Fuss zu fassen, und wenn danach > wieder kein seq. Code da ist gehts von vorne los, und gurgt vor sich > hin) Den F4 kenne ich nicht konkret, das Flash-Interface der LPC2000 hingegen besser. Und da kriege ich keinen Code zusammen, der deiner Vorstellung entspricht. > Renesas erwähnt das halt, weil andere es auch machen. Also gut, wo erwähnt Renesas den eklatanten Vorsprung gegenüber der Konkurrenz von Faktor 20 denn? Britisches Understatement ist in der Branche ziemlich unüblich. > Und ein ARM Benchmark der ausm RAM läuft ist eine Lachnummer, hat mit > Realität extrem wenig bis nichts zu tun, weil schlichtweg nicht alles > reinpasst. (bzw kann man nur einen extrem kleinen Codteil darauf > anwenden). Was kein Problem ist, da kaum jemals mehr als ein paar Prozent eines Programmes stark laufzeitrelevant sind. Einzelne Funktionen ins RAM zu legen ist bei ARMs gängige Praxis und sehr real. > RX kann all das das, was (der olle) ARM kann, und vieles mehr. > kannst du (ausser Hoffnung) definitv nichts entgegen setzen. Habe ich auch nicht vor. Nur sehe ich summarum einen Vorsprung von eher 1,5 bei gleichem Takt, nicht 20. Das ist nicht zu verachten, aber nicht annähernd die Dimension, die du skizzierst. Ich habe auch nicht das geringste Problem damit, wen Leute Renesas verwenden. Nur habe ich ein Problem mit dem Unsinn, den du regelmässig verzapfst, wenn von ARM die Rede ist.
>Und weshalb sollte mich jeder einzelne Takt stören, wen die geforderte >Zeitbedingung beispielsweise im Millisekundenbereich liegt? Aber nicht wenn ns sind. >> Denn du weisst überaupt nicht WIEVIELE sequentielle Befehle aufeinander >> folgen. >Nein? Bei einer IBM650 wirds kompliziert, aber nicht so bei ARMs. Wenn du die (wie andere auch) ja zählen kannst, dann wüsstest/weisst du, dass gerade bei Steuerungsanwendungen extrem oft unseq. Codeeteile vorh sind, und somit der Acc. fast immer ausser Betrieb ist ..was schon wieder auf beschr. worstcasefall hindeutet. hinzu kommt, wenn INT auftr. (wenn nicht aus ram läuft) auch dann nicht seq., also worstcasefall massgebend. Statistik ist nicht Worstcase! Eine CPU mit 25MHz Flash-f und 250MHz CPU-Takt heisst nichts anderes, als dass sich die wirkl. f zwischen 25...250MHz bewegt. sind Worstcase 25 MHz. >Also gut, wo erwähnt Renesas den eklatanten Vorsprung gegenüber der >Konkurrenz von Faktor 20 denn? Steht im DB. Aus f's und einzelnen Bef. zu ersehen. Natürlich kommt es auf die konkr Anwendung an, der Faktor ist nat. nicht immer da. Man kann ja auch i.e. ARM-Code laufen lassen, dann ist der Faktor weitaus geringer. >Nur sehe ich summarum einen Vorsprung von grob >50% bei gleichem Takt. Nö. konkret interessiert, nicht statistik.
>Nur habe ich ein Problem mit dem Unsinn, den du regelmässig >verzapfst, wenn von ARM die Rede ist. Den Unsinn verzapfst du, denn du kannst Statistik nicht von WorstCase unterscheiden. Auch dein Beispiel mit der Autobahnfahrt zeigt das.
Piet schrieb: > bei der Suche nach einer leistungsfähigeren Alternative zu AVR ATMegas Piet, bleib bei AVR und nimm den Xmega, wenn nicht gerade viel mehr Leistung oder es just für den Job nötig ist.
Moby schrieb: > Piet, bleib bei AVR und nimm den Xmega, wenn nicht gerade viel mehr > Leistung oder es just für den Job nötig ist. Ist ein wenig offtopic, aber die XMegas laufen eben mit vollen 32 Mhz im Core und bis zu 16Mhz in der Peripherie. Ich habe hier eine Applikation ( 3-Phasen Sinus BLDC) , die ich auf 3 verschiedenen Architekturen implementiert habe: ATMega88/168 bei 8/16Mhz, XMega192A3 bei 32Mhz und STM32F103 (netto ca.25Mhz). Die Hauptschleife misst, wieviel Zeit die CPU 'übrig' hat und erledigt nebenbei die Konsole, der Motor läuft komplett im Interrupt. Und siehe da, der XMega ist eindeutig der flinkeste. Dazu sei gesagt, das ich bei allen 3 Projekten die jeweilig passendste Peripherie benutze, also AWEX beim XMega und den 'Advanced Timer' beim STM32. Beim Mega88 haste nur die drei Timer und musst den Rest zu Fuss machen. Wilhelm Ferkes schrieb: > Genau das ist es ja, meine Fragen. Nicht, daß ich bei der Toolchain auf > einem Rest von 10% sitzen bleibe, und das streng limitiert ist. Oder > einen Teil davon gar nicht bekomme. Dann schau dir Coocox an, soweit ich mitbekommen habe, ist da kein Limit drin und es soll nach ein wenig (mehr) Konfigurationsgefummel brauchbar laufen. Ich hab immer überlegt, ob das Eclipsedings vllt. alles andere hier ersetzen könnte, also von MIDE51 für 8051 Saurier über AVR Studio 4 und 6 bis zu Atollic für die STM32 - das ist aber, denke ich, ein Wunschtraum. > Ich muß ja mit den berühmten 374 Euronen Lebensunterhalt im Monat rund > kommen, du weißt sicher, was ich meine. ;-) Oh, das kenne ich. Ich habe Monate, da wäre ich happy, wenn ich 374 Mäuse hätte.
Der Vergleich ARM:RX ist ein bißchen wie das Märchen Hase:Igel. RX ist eine Gattung von einem Hersteller; ARM ist ein Oberbegriff für viele Gattungen mehrerer Hersteller. Wenn man sagt, ein ARM (speziell gemeint ein STM32F4) kann dies oder das nicht, kann schnell jemand kommen und sagen: "Der ARM vom Hersteller xyz kann das sehrwohl." Da kann man sich (ich) als Igel schnell totlaufen. Reduzieren wir doch den "Vergleich" auf den STM32F4, der wegen seiner äußerst günstigen Demoboards ein MUSS zum Spielen ist, und auf den RX62N/RX621, der allerdings mit "nur" 100MHz betrieben werden soll. So. Und jetzt möchte ich gerne etwas zum DMAC sagen. Bei der Anwendung, die Chris oben beschreibt, laufen Schreib- und Lesezeiger synchron von einem Timer getriggert. Das kann der F4. Jetzt möchte ich aber den DMAC per ext. Anforderung triggern, um einen Transfer (Byte, Burst, Block, ...) auszulösen. Der RX62 hat dafür einen speziellen ExDMAC, der einen ext. EDREG zum Auslösen erlaubt und mit EDACK quittieren kann. (Früher gab's dafür den 8257 :-) Korrigiert mich, wenn ich falsch liege: das kann der DMAC vom F4 nicht. Dies zum DMA-Controller. Solange man mit dem internen SRAM als Puffer auskommt, ist obiger Ringpuffer kein Problem. Aber wie sieht es aus, wenn 16MB als Puffer gefordert werden?
Wilhelm Ferkes schrieb: > Etwas kastriert allerdings. Der Code wird aus dem Programmspeicher auf > jeden Fall in 16 bit geholt, nicht in 32 bit. Instruction memory wird bei allen ARM Prozessoren, spätestens seit ARM9E in voller Busbreite addressiert. D.h. beim Cortex-M3 32bit. Die Befehle werden dann erst im Prefetch buffer auseinanderklamüsert. -- Marcus
A. K. schrieb: > Da wirds etwas komplizierter. Grundsätzlich hast du Recht. Es sind viele Parameter im Spiel, bis zum Halbleiterprozeß, das ist mir gar nicht unbekannt. Chris D. schrieb: > Zwei Audiosignale werden per externem ADC mit je 16 Bit gewandelt und > per I2S an den STM32F4 geschickt. Interessant. Exakt sowas hat ein mehr als 5 Jahre altes 8051-Board von SiLabs, was ich noch hier rum liegen habe. Der hat integrierte 16-bit-ADC, die direkt über DMA in allerdings externe 128k SRAM schreiben. Das Eval-Board hat sogar 2 BNC-Buchsen, also nicht mal eben nur für Netzfrequenz, die Samplingrate müßte ich mal nachschauen, die Jungs gaben sich etwas Mühe. Die blöde Demo ist ein Hex-Code, dummerweise kein Quellcode, wo eine FFT gemacht wird, die grafisch auf einem eben so blöden PC-Tool ausgegeben wird. Das kann man leider nur anschauen, und nichts dran bewegen oder ändern. Womit ich am Rande mal wieder sage: Der 8051 ist noch nicht weg. Und wenn ein Teil von Fetischisten den aufrecht erhält, bis die ausgestorben sind. ;-) Ansonsten klingt die Sache mit dem Discovery-Board nach wie vor gut.
Wilhelm Ferkes schrieb: > klingt die Sache mit dem Discovery-Board nach wie vor gut ...klingt gut. Aber man muß schon den Göttern der Komplexität huldigen und sich damit abfinden können daß alles komplizierter ist als für die konkrete Anwendung nötig. Wer sich statt auf Tausend Tools und Treiber lieber auf eine konkrete Anwendung konzentrieren möchte bleibt beim Xmega- den kann man in der Tqfp-44 Variante sogar noch selber löten, das eine Tool (Studio6) ist kostenlos und man hat noch eine Chance assemblermäßig den Dingen auf den Grund zu gehen! P.S. hab mir aus Neugier auch das Discovery besorgt- und alle schlimmen Erwartungen s.o. bestätigt gefunden.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.