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.
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.
Golem schrieb: > 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! hmmm dann wäre ich wohl auch besser beim meinem Sharp MZ700 mit Z80 CPU geblieben..... neue PC sind einfach zu komplex demnach :D
Jörg B. schrieb: > neue PC sind einfach zu komplex demnach Nö. Mit Windoof ist doch alles ganz einfach... Aber Mann/Frau soll es doch einfach ausprobieren und vergleichen. Muß halt jeder seine Erfahrungen machen.
Jörg B. schrieb: > dann wäre ich wohl auch besser beim meinem Sharp MZ700 mit Z80 CPU Mehr Leistung bedingt nicht zwangsläufig mehr Komplexität in der SW Entwicklung- das ist eindeutig ein Trugschluß.
Golem schrieb: > 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. Man muss ja nicht direkt alles einsetzen. Ich sehe nicht, dass die Dinge, die wir z.Z. noch per AVR erledigen, durch die STM32 viel komplizierter geworden wären. Durch die von ST mitgelieferten Bibliotheken ist es aber natürlich anders geworden. Aber: man kann damit eben doch noch viel weiter hinaus - wenn man möchte. > Wer sich statt auf Tausend Tools und Treiber Tausend Tools und Treiber? Hier läuft Eclipse und die Toolchain - genauso wie beim AVR. > 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 geht bei den meisten Gehäusen der STM32 auch noch ohne Probleme. > eine Tool (Studio6) ist kostenlos Eclipse, GDB und diverse Werkzeugketten auch. > und man hat noch eine Chance > assemblermäßig den Dingen auf den Grund zu gehen! Das hat man auch weiterhin. > P.S. hab mir aus Neugier auch das Discovery besorgt- und alle schlimmen > Erwartungen s.o. bestätigt gefunden. Das kann ich nicht wirklich nachvollziehen. Einarbeiten musste ich mich beim AVR genauso wie jetzt bei den STMs. Aber komplizierter? Nur, wenn man komplexe Dinge machen möchte. Man muss ja nicht direkt mit dem DSP im STM32F4 beginnen - aber man kann eben, wenn man möchte. Chris D.
Chris D. schrieb: > Ich sehe nicht, dass die Dinge, die wir z.Z. noch per AVR erledigen, > durch die STM32 viel komplizierter geworden wären. Ich finde eine solche Aussage wirklich nur noch albern. So gut wie alles ist komplexer, um nicht zu sagen umständlich. Nun gut, mich zwingt zum Glück keiner, war die pure Neugier :-)
Golem schrieb: > 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. Ach, das ist doch schon ganz toll, daß auf den modernen Chips alle möglichen und unmöglichen Peripherals fertig drauf sind. Man muß ja nur eine Teilmenge davon gebrauchen, und freut sich, wenn man später noch was anderes macht, was auf dem Chip auch schon drauf ist. Auch heute kann man auf dem Teil nichts weiter als nur eine LED blinken lassen, wenn man das gerne möchte. Jedenfalls kenne ich die andere Seite, bspw. 8048 und 8085. Beide kann ich nicht direkt an eine RS232 hängen, um z.B. Debug-Ausgaben am Terminal zu machen. Denn sie haben beide noch nicht mal einen UART. Der 8085 hat noch nicht mal einen Timer. Wenn man das alles braucht, muß man externe Bausteine verwenden. Zwar habe ich da als Notlösung so Bitbanging-Codeteile, aber die beanspruchen den Prozessor ja voll, weil sie nicht vollautomatisch laufen. Interessehalber baute ich mir mal ein 8085-Board mit externem Timer und externem I/O (ja, das brauchte der auch!). Leider paßte auf die Europa-Karte kein UART-Baustein mehr, zu wenig Platz. Und ein Mords-Verdrahtungsaufwand. Mit den LPC2000 (ARM7) kam ich hervorragend zurecht. Vermutlich aber eher, weil ich am PC Profi-Tools von Keil hatte, ready to use. Installieren und los legen. Wegen der einfachen Überschaubarkeit möchte ich auch meine 8051-er nicht aufgeben.
Wilhelm Ferkes schrieb: > Jedenfalls kenne ich die andere Seite, bspw. 8048 und 8085. Beide kann > ich nicht direkt an eine RS232 hängen, um z.B. Debug-Ausgaben am > Terminal zu machen. Denn sie haben beide noch nicht mal einen UART. Der > 8085 hat noch nicht mal einen Timer. Wenn man das alles braucht, muß man > externe Bausteine verwenden. Da hängt man doch einen AY-3-1015 dran - um in der Zeit zu bleiben. Toteinfach das Teil, nur den Baudratentakt muss man zuführen. Aber keine komplizierte Initialisierung nötig, funzt einfach.
Golem schrieb: > Chris D. schrieb: >> Ich sehe nicht, dass die Dinge, die wir z.Z. noch per AVR erledigen, >> durch die STM32 viel komplizierter geworden wären. > > Ich finde eine solche Aussage wirklich nur noch albern. > So gut wie alles ist komplexer, um nicht zu sagen umständlich. Du hast einfach viel mehr Möglichkeiten. Entsprechend muss man eben auch mal den einen oder anderen Parameter mehr setzen. Aber dafür gibt es ja die ST-Bibliotheken. Das simple Füllen eines Structs sollte einen nicht wirklich überfordern. > Nun gut, mich zwingt zum Glück keiner, war die pure Neugier :-) Eben. Aber mit "Nur mal kurz Reinschnuppern" wird man sich in keine neue Controllerfamilie einarbeiten. Da erscheint dann natürlich alles fremd und umständlich. Man braucht seine Zeit. Deswegen mache ich das jetzt auch ein paar Monate nebenher, bevor wir dann wirklich von AVR auf ARM umsteigen. Chris D.
A. K. schrieb: > Da hängt man doch einen AY-3-1015 dran - um in der Zeit zu bleiben. > Toteinfach das Teil. Keine Initialisierung nötig, funzt einfach. Den kannte ich noch nicht, habe aber das Datenblatt gerade mal schnell überflogen, scheint sowas wie 8250 zu sein. Von dem habe ich noch Reserven, aber die Platine war schon voll. ;-) Für ein paar Spielereien, ich wollte die 8085-Karte ja nur als Retro-Teil mit ein paar blinkenden LEDs am 8255, nicht mehr für eine echte Entwicklung, dafür reicht es.
> Einarbeiten musste ich mich beim AVR genauso wie jetzt bei den STMs. > Aber komplizierter? Nur, wenn man komplexe Dinge machen möchte. Das stimmt nicht. Das grosse Problem der ARMs ist das es sie von verschiedenen Herstellern gibt und es da grosse Unterschiede gibt. Dann gibt es verschiedene Oberflaechen mit denen du arbeiten kannst, du kannst verschiedene Compiler einsetzen. Und zum Abschluss gibt es auch noch verschiedene Debugger. Da gibt es riesige Permutationsmoeglichkeiten, Softwarestaende die nicht zusammenpassen, Beispiele die nicht fehlerfrei sind. Wer bisher nur die Tools eines Hersteller gewohnt ist (Renesas:HEW, AVR:Studio) wo alles an die jeweiligen hauseigenen Bausteine angepasst ist, der wird da schwer ins staunen kommen. Und wenn man sich dann bisher nur als Gelegenheitsprogrammierer durchs leben geschummelt hat der seine Codes nur im Internet zusammengeklaut hat dann wird man erst recht staunen. (z.B wird es ploetzlich wichtig structs zu packen, oder je nach Taktfrequenz und Spannung die Waitstates anzupassen) Andererseits wenn man einmal damit klarkommen ist dann moechte man ganz gewiss niemals mehr einen ollen MCS51 programmieren. Nein danke, wirklich nicht! Olaf
Wilhelm Ferkes schrieb: > Den kannte ich noch nicht, habe aber das Datenblatt gerade mal schnell > überflogen, scheint sowas wie 8250 zu sein. Nein, eben nicht. UART ja, aber konfigurationsfrei. Also was die Software angeht. Alle Parameter wie die Anzahl Bits und die Parity liegen auf Pins. Mit dem Ding kriegst du einen 100% intelligenzfreien Parallel/Seriell-Wandler gebacken. So einen hatte ich vor ein paar Jahren man in einem Retro-Projekt verbraten, als Bootloader für einen ROM-freien RCA 1802: Beitrag "Re: RAM mit Adresslatch gesucht"
A. K. schrieb: > Mit dem Ding kriegst du einen 100% intelligenzfreien > Parallel/Seriell-Wandler gebacken. Das Dings habe ich genau dafür auch mal genutzt, einen parallelen Drucker per Optokoppler über 100m zu übertragen, Wandlerkästchen auf beiden Seiten und dann über Telefonleitung hin und zurück. Ist allerdings 20 Jahre her. Kaufen kannst du den AY-3-1015 nicht mehr, weiss nicht mal, ob GI überhaupt noch ICs herstellt. Thema: Was bei STM wirklich sehr gewöhnungsbedürftig ist, ist die Dokumentation. Das ist ein Hin- und Hergeschiebe zwischen PDFs mit schwierig zu kapierenden Beschreibungen, vor allem wenn es ums eingemachte geht, wie den Advanced Timer, ADC mit mehreren Kanälen und sonstige Spezialitäten. Das mehrere Kanäle beim ADC nur mit DMA gehen, ist z.B. in der Doku nicht klar. Beim XMega blättert man ja auch schon ständig zwischen Family- und Chipdoku hin und her, aber bei STM kommt dazu noch die eigenartige Umschreibung. Hat mich viel Zeit gekostet.
Golem schrieb: > Chris D. schrieb: >> Ich sehe nicht, dass die Dinge, die wir z.Z. noch per AVR erledigen, >> durch die STM32 viel komplizierter geworden wären. > > Ich finde eine solche Aussage wirklich nur noch albern. > So gut wie alles ist komplexer, um nicht zu sagen umständlich Ich finde diese Aussage auch nicht in Ordnung. Selbst, wenn man schon eine gewisse Programmiererfahrung hat und genau weiß, was man machen möchte, bedarf es doch einer deutlichen Einarbeitungszeit. Dies anschließend kleinzureden, drückt in meinen Augen Überheblichkeit aus. Beispielsweise finde ich einige Punkte beim STM32 überhaupt nicht anwenderfreundlich. Die Register für die io-Programmierung werden zwar in Strukturen angeordnet, aber diese Strukturen sind unnötiger Weise zusammengequetscht. Nehmen wir die Register-Struktur für den DMA-Controller. Alle acht Kanäle werden in eine Struktur gepackt, wobei in einzelne Registern aber Bits für unterschiedliche Kanäle gepackt werden (zum Beispiel DMA_LISR für Kanäle 0-3). Beim RX wird eine Struktur für einen DMA-Kanal definiert, die für alle Kanäle identisch ist. Das Ansprechen der einzelnen Kanäle unterscheidet sich anschließend nur in der Startadresse. Beim Deguggen ist dies viel transparenter. Schließt man ext. Speicher an einen STM32F4 an, wird man feststellen, dass Adress- und Datenleitungen etwas willkürlich auf die Portpins gewürfelt wurden. Beim RX werden Adressen und Daten 'geordnet' auf die 8 Bit breiten Ports gelegt: Beispiel D0-D7 auf PD0-PD7, D8-D15 auf PE0-PE7, A0-A7 auf PA0-PA7, ... Für mich sind das Gründe, warum der RX angenehmer zu handhaben ist.
Natürlich ist ein Auto komplizierter als ein Seifenkistl. Trotzdem möchte ich auf mein Auto nicht verzichten. In der Praxis bedient man das Auto irgendwann wie im Schlaf. So ist es auch mit den ARM. Zudem baut man doch neue Projekte stets auf alten, bewährten Code auf. Deshalb ist es letztlich wirklich kaum komplizierter als beim AVR. Natürlich gibt es eine Eingewöhnungsphase, wo man halt durch muss ...
m.n. schrieb: > Golem schrieb: >> Chris D. schrieb: >>> Ich sehe nicht, dass die Dinge, die wir z.Z. noch per AVR erledigen, >>> durch die STM32 viel komplizierter geworden wären. >> >> Ich finde eine solche Aussage wirklich nur noch albern. >> So gut wie alles ist komplexer, um nicht zu sagen umständlich > > Ich finde diese Aussage auch nicht in Ordnung. Selbst, wenn man schon > eine gewisse Programmiererfahrung hat und genau weiß, was man machen > möchte, bedarf es doch einer deutlichen Einarbeitungszeit. Dies > anschließend kleinzureden, drückt in meinen Augen Überheblichkeit aus. Ich habe da nichts kleingeredet und war ganz sicherlich nicht überheblich. Aber man kann doch nicht ernsthaft erwarten, dass man nach flüchtiger Beschäftigung mit einer neuen Architektur über vielleicht ein bis zwei Wochen dieselben schnellen Ergebnisse erhält wie mit einer, die man schon Jahre (ich mittlerweile über 11) kennt. Man muss sich nun einmal in eine neue Architektur einarbeiten - genau das muss ich auch und das schrieb ich auch so. Zu den verschiedenen Herstellern: Diversität hat Vor- und Nachteile. Ich empfinde es als angenehm, dass ich zwischen verschiedenen IDEs wählen kann und z.B. mit einer einzigen Kombination (Eclipse + GCC/GDB) sowohl für ARM als auch AVR entwickeln kann. Wenn ich zu einem anderen Hersteller gehe, dann wechsele ich im Prinzip nur das HAL aus - der ganze Rest der Entwicklungsumgebung bleibt. Thomas hat das schön beschrieben: wenn ich vom Fahrrad auf ein Auto umsteige, dann muss man das auch erstmal länger lernen, bis alles in Fleisch und Blut übergegangen ist. Aber dafür eröffnen sich auch ganz andere Möglichkeiten. Chris D.
@A.K.: OK, hast gewonnen. Ich kenne die alten Familien gar nicht so. Und in ein paar Minuten bekomme ich das im Detail auch nicht hin. Das einzige, was ich machte, als ich mit 8051 einstieg: Ich beschäftigte mich fast ausschließlich auch mit deren Vorgängern 8048 und 8085, bzw. 8085-Peripheriebausteinen, eben weil die auch zum 8051 passen. Also mit der Intel-Familie. Und da längst auch nicht mit allen. Einfach, um etwas mehr darüber zu erfahren, wie der 8051 zu Stande kam. Irgendwo haben diese Bausteine Intel 8-Bitter ja alle noch Parallelen, Gemeinsamkeiten. Thomas Winkler schrieb: > Zudem baut man doch neue Projekte stets auf alten, bewährten Code auf. Sagen wir es so: Der normale Funktionscode, Algorithmen, was nicht direkt hardwareabhängig ist, kann gelegentlich bleiben, wie er ist. Aber eine kleine Portierung bei den Peripherals ist mindestens schon nötig. Das kann unter Umständen noch etwas stressiger werden. Ich portierte mal 8051 auf einen ARM. Oder, wenn man beim 8051 die eingebauten Interrupt-Prioritäten nutzte, die es beim LPC2000 gar nicht so direkt gibt, da muß man sich was anderes einfallen lassen.
Chris D. schrieb: > ... Ich möchte noch hinzufügen, dass ich alle dargestellten Punkte (seien es Vorteile oder Kompromisse) von Chris teile. Auch der Vergleich mit dem Auto trifft es ganz gut. Das ist eine sehr schöne und objektive Darstellung der Tatsachen.
Damit die "ARM" Anfänger es leichter haben, gibt es im Artikel STM32 hier ein paar Tipps für Umsteiger: http://www.mikrocontroller.net/articles/STM32#Tipps_f.C3.BCr_Umsteiger_von_Atmel.2FPIC.2F8051 Und das sollte doch wirklich für jeden zu lernen sein. Wenn jemand von einem AVR auf einen PIC umsteigt, so wird er auch erst mal ein paar Problemchen zu lösen haben, der Aufwand von AVR zu ARM ist nicht wirklich größer. Nur dass man da etwas mehr lesen muss (Doku, Reference Manual, Datasheet).
Olaf schrieb: > Andererseits wenn man einmal damit klarkommen ist dann moechte man ganz > gewiss niemals mehr einen ollen MCS51 programmieren. Nein danke, > wirklich nicht! Ja doch, wenn man sie in- und auswendig kennt, auch die Toolchain, lange damit arbeitete, und noch Bausteine bzw. Boards hat. Für eine relativ einfachere Sache, wie eine simple Waschmaschinen-"Steuerung", ist der doch gut angebracht. Für einen blinkenden Weihnachtsbaum käme ich nie auf die Idee, ARMs einzusetzen. Wenn man aber in die neuen Dinge mal eingearbeitet ist, und die neuen leistungsfähigeren Bausteine auch nicht mehr teuerer sind, da läßt sich drüber reden, ganz klar. Und bspw. SiLabs haben hoch moderne 8051-Derivate mit Peripherals, das läuft schon fast wieder auf den STM32F4 hinaus.
Wilhelm Ferkes schrieb: > Für einen blinkenden Weihnachtsbaum käme ich nie > auf die Idee, ARMs einzusetzen. Da muss ich entschieden widersprechen. Der STM32 hat bis zu 32 PWM Ausgänge die separat geschaltet werden können, somit kann man die Lichterkette mit bis zu 32 Kanälen wunderschön dimmen und die verschiedensten Muster generieren. Ich glaube Dir fehlt noch etwas der Überblick über die Leistungsfähigkeiten und den daraus resultierenden Möglichkeiten. Steht schön zusammengefasst im Artikel STM32
> Wenn jemand von einem AVR auf einen PIC umsteigt, so wird er auch erst > mal ein paar Problemchen zu lösen haben, der Aufwand von AVR zu ARM ist > nicht wirklich größer. Nur dass man da etwas mehr lesen muss (Doku, > Reference Manual, Datasheet). Nach einigen Beiträgen hier könnte man aber meinen daß ein Umstieg von avr nach RX ohne weiteres Zutun möglich wäre... Ich könnte gerade übrigens einen CAN RX im QFN Gehäuse brauchen. Vorschläge?
Wilhelm Ferkes schrieb: > Sagen wir es so: Der normale Funktionscode, Algorithmen, was nicht > direkt hardwareabhängig ist, kann gelegentlich bleiben, wie er ist. Aber > eine kleine Portierung bei den Peripherals ist mindestens schon nötig. > Das kann unter Umständen noch etwas stressiger werden. Ich portierte mal > 8051 auf einen ARM. Nicht unbedingt. Wenn man die Aufgabe hat, auf mehreren Plattformen tätig zu sein, dann baut man sich eben dafür Tools auf. Man abstrahiert alle gängigen Aufgaben. Man schafft sich seinen Standardcode für Grundaufgaben. Rentiert sich halt nur wenn man viel Software hat die man portieren möchte.
Markus Müller schrieb: > Ich glaube Dir fehlt noch etwas der Überblick über die > Leistungsfähigkeiten und den daraus resultierenden Möglichkeiten. Das stimmt schon. Aber, je mehr, desto besser. Schade finde ich, daß das Discovery-Board ausgerechnet keinen CAN hat, denn genau dafür machte ich anderswo schon mal Software, und sowas könnte ich gebrauchen. > Man abstrahiert alle gängigen Aufgaben. Man schafft sich seinen > Standardcode für Grundaufgaben. Schon klar. In der Kleinklitsche ging es oft darum, schnellstmöglichst die Lösung zu haben. Also wirklich ZZ, ziemlich zügig. Keine Zeit zum Nase bohren. Da konnte man sich oft auch nicht mit ästhetisch schönem Code befassen, geschweige denn mit dem Tools-Setup.
Einen MCP2551 oder PCA82C250 an die entsprechenden Portpins ran löten und schon hat das Discovery auch CAN.
...oder den hier. (Mod.: Anhang pdf entfernt, stattdessen: http://www.ti.com/lit/ds/symlink/sn65hvd230.pdf )
Markus Müller schrieb: > Einen MCP2551 oder PCA82C250 an die entsprechenden Portpins ran löten > und schon hat das Discovery auch CAN. Schon klar. Aber er ist eben nicht integriert.
Wilhelm Ferkes schrieb: > Schon klar. Aber er ist eben nicht integriert. Was erwartest du noch für das Geld????
Oft wird der CAN galvanisch getrennt benötigt, da ist es sogar ein Vorteil, dass der nicht drauf ist. Noch ein ADUM1201 und DCDC Wandler dazwischen und schon hat man das auch.
Markus Müller schrieb: > Oft wird der CAN galvanisch getrennt benötigt, da ist es sogar ein > Vorteil, dass der nicht drauf ist. Noch ein ADUM1201 und DCDC Wandler > dazwischen und schon hat man das auch. Wie schon gesagt: Ich möchte nicht noch mal so anfangen, als man beim 8085 externe Peripherals benötigt.
Viel Spass. Herrje, das ist ein Transceiver, keine Peripherie. Schon mal einen µC mit integrierter 50V/10A Vollbrücke gesehen?
A. K. schrieb: > Viel Spass. Herrje, das ist ein Transceiver, keine Peripherie. Schon mal > einen µC mit integrierter 50V/10A Vollbrücke gesehen? Bei NXP überlegte man, sogar den CAN-Transceiver mit in den µC hinein zu verlegen. Ich verfolgte das aber nicht mehr, in wie weit das inzwischen gediehen oder auch nicht gediehen ist.
Ich weiss, das gibt es vereinzelt. Aber deine Aussage war doch etwas arg fundamentalistisch. Und so ein Transceiver ist nun wirklich kein Monster. Ethernet-PHYs sind weit schlimmer.
Wenn die Stromversorgung des µC doch schon galvanisch getrennt ist, wo ist denn da bei CAN ein Problem?
Wilhelm Ferkes schrieb: > A. K. schrieb: > >> Viel Spass. Herrje, das ist ein Transceiver, keine Peripherie. Schon mal >> einen µC mit integrierter 50V/10A Vollbrücke gesehen? > > Bei NXP überlegte man, sogar den CAN-Transceiver mit in den µC hinein zu > verlegen. Ich verfolgte das aber nicht mehr, in wie weit das inzwischen > gediehen oder auch nicht gediehen ist. Hallo Wilhelm, Ich arbeite mich z. Zt. in den C8051F580 ein und der hat schon alle wichtige Peripherien in ausführlicher Ausstattung. Der eingebaute CAN Bus Controller scheint auch vieles ohne CPU Mitarbeit zu erledigen. Irgendwie finde ich dem MCU ganz gut konzipiert. Auch gibt es nur drei Minor ERRATA. Viele andere MCU haben eher voluminöse ERRATA Buechlein;-) Naja, für mich ist dieser MCU noch ganz neu. Muss mal sehen wie viele Zähne ich mir dabei ausbeissen werde... (Obwohl der Vergleich hinkt, schlimmer als ein STM32 kann der bestimmt nicht sein und mit denen komme ich gut zurecht). mfg, Gerhard
Wilhelm Ferkes schrieb: > Bei NXP überlegte man, sogar den CAN-Transceiver mit in den µC hinein zu > verlegen. Ich verfolgte das aber nicht mehr, in wie weit das inzwischen > gediehen oder auch nicht gediehen ist. Der LPC11c22/24 hat den Transceiver eingebaut.
Gerhard O. schrieb: > Hallo Wilhelm, > > Ich arbeite mich z. Zt. in den C8051F580 ein und der hat schon alle > wichtige Peripherien in ausführlicher Ausstattung. Der eingebaute CAN > Bus Controller scheint auch vieles ohne CPU Mitarbeit zu erledigen. > > Irgendwie finde ich dem MCU ganz gut konzipiert. Auch gibt es nur drei > Minor ERRATA. Viele andere MCU haben eher voluminöse ERRATA Buechlein;-) ERRATA heißen heute auch schon wieder anders, wenn ich das richtig vernahm. > Naja, für mich ist dieser MCU noch ganz neu. Muss mal sehen wie viele > Zähne ich mir dabei ausbeissen werde... (Obwohl der Vergleich hinkt, > schlimmer als ein STM32 kann der bestimmt nicht sein und mit denen komme > ich gut zurecht). > > mfg, > Gerhard Die modernen SiLabs-Derivate haben allerdings mit dem echten 8051 kaum noch was zu tun. Es sind taktreduzierte MCU, die auch noch eine Pipeline haben. Die Zyklen etwas anders, als beim UR-8051. Aber ich wünsche dir viel Erfolg damit. Wir wollen ja nicht alle mit einem µC eine fertige Mondrakete bauen, sondern die Unzahl viel einfacherer Dinge.
Jörg B. schrieb: > Der LPC11c22/24 hat den Transceiver eingebaut. Dann machten sie es also doch. Leider kenne ich nur die LPC2100/2200. Ist schon eine Weile her.
Chris D. schrieb: > Ich habe da nichts kleingeredet und war ganz sicherlich nicht > überheblich. Das war auf die Schnelle etwas direkt formuliert und nicht speziell gegen Dich gerichtet. Aber ausgehend von der Eingangsfrage Umstellung 'AVR->ARM == kompliziert' und der vielfachen "Schönbeterei" kann bei einem Umsteigewilligen die Vorfreude auch schnell in Frust umschlagen. Golem hat sich ja dahingehend geäußert. Ich denke, die meisten Leute hier haben, ebenso wie ich, erst einmal mit einem Discovery-Board und überschaubaren Funktionstests in den STM32F4 hineingeschnuppert. Wenn dann daraus die Meinung abgeleitet wird, nur noch ARM nie wieder AVR, zeigt es, dass garnicht objektiv beurteilt wird: "ARM ist kostenlos bis billig und damit das non plus ultra." Das ist mir (und Olaf sicherlich noch mehr) eine viel zu einseitige Sichtweise. Wer anstatt Fahrrad lieber Auto fahren möchte, der muß auch die Spritpreise akzeptieren.
Ich hab mir diesen (mittlerweile) Monsterthread mal komplett durchgelesen. Und irgendwie find ich es trotzdem immer wieder interessant welche Flame-Wars vom Zaun gerissen werden wenns um die eine oder andere bevorzugte Architektur bzw uC-Familie geht :-) Aber es ist tlw auch sehr lehrreich durch die ganzen Side-Infos. Ich selbst hab mittlerweile auch schon mit einigen uC-Familien gearbeitet (MSP430, AVR, PIC, Renesas), und jede Familie hat ihre tollen Seiten, aber auch ihre Macken. Ich denke so wirklich "die" ultimative Empfehlung wird man nicht geben können, da sind wir uns denke ich alle einig. Es kommt auf den Anwendungsfall an. Und sich hobbymäßig damit zu beschäftigen erfordert eben immer was Zeit um sich in die Familie einzuarbeiten. Am wenigsten Probleme hatte ich bisher mit den PICs (das Eval-Kit lief direkt auf anhieb). Beim AVR wäre es wahrscheinlich genauso schnell gegangen wenn ich mit einem STK 500 angefangen hätte, aber ich hatte anfangs ein wenig Probleme die Eigenheiten der AVRs zu verstehen. Vorher hab ich mit MSP430 gearbeitet, und da war eben linearer Adressraum, einzelne Bytes/Words im Flash lassen sich zur Laufzeit umprogrammieren, die "Fuse-Bits" konnten per SW zur Laufzeit geschrieben werden. Da wirkte der AVR doch eher minimalistisch. Aber dennoch find ich die AVRs recht gut. Gerade für Einsteiger, und bei den Tutorials die es hier auf uC.net gibt ist das mit einm bissl Hirnschmalz kein Problem. Mit den ARMs hab ich schon immer ein bissl auf Kriegsfuß gestanden. Aber weniger wegen der Architektur, sondern eher wegen den div. Toolchains, Startup-Codes und Wiggler bzw Programmer-Problemen. Hab mich an einem LPC2106, einem AT91SAM7 und an einem STM32 probiert. Am besten hat mir die Rowley-IDE gefallen. Da hab ich mit dem AT91 einiges geschafft und war auch recht begeistert. Beim STM32 hatte ich das Primer, war aber ziemlich enttäuscht von der IDE, da viele Demos nicht mal eben liefen, bzw man ein bissl Tricksen musste um das CircleOS abzuschalten. Und das obwohl die reinen Daten des STM32 mich schon überzeugt haben. Ich für meinen Teil werd mich definitiv noch mit den ARMs beschäftigen, aber find es halt was "nervig" das man zig verschiedene Startup-Codes braucht, und das Debugging bzw Programmieren nicht immer so einfach ist wie beispielsweise bei einem PIC oder AVR. Das ist für mich momentan (neben dem Wust an IDE's und Toolchains) das einzige was mich stört. Da wäre eine IDE ähnlich wie die AVR-Studio einfach was feines. Und dann noch mit nem ARM-GCC der eben keine Code-Größen-Beschränkung hat, und "relativ" leicht einzurichten ist. Das wär mal nen echt schönes Paket. Das es solche Pakete gibt weiß ich (Yagarto, aber das lief bei mir nicht wirklich). Daher schwanke ich momentan zwischen dem STM32F4 (weil die Prozis einfach schön viel Flash und RAM haben, aber ich mal schauen muß mit welcher Toolchain und IDE das am einfachsten geht, und ich mal wirklich "eben" loslegen kann) und nem LPCXpresso (wo eben eine Codegrößenbeschränkte, aber komplette IDE dabei ist, und man direkt loshäcken kann :-)). Edit : Hab wohl nicht richtig gelesen als von CooCox und F4 die Rede war. Mmh, ich glaub dann fällt meine nächste "Investition" wohl auf ein STM32F4 Discovery Board und CooCox. Zumal das Board bei RS schon für 12 Euro zu haben ist (wenn ich das nicht auch falsch gelesen hab :-))
Viele loben hier die Coocox-IDE. Ich habe mit den Sachen keine guten Erfahrungen gemacht. Allerdings in Verbindung mit einem LPC1769. Die beiden Stm32 Boards (Discovery) habe ich mal angetestet. Mit den darauf verbauten st-link Adaptern geht das Debuggen ganz gut. Aber beim LPC1769 (auf einem SIMPLECORTEX Board http://www.brc-electronics.nl/) ist es nur noch Krampf. Hier ist der Colinkex jtag/swd Adapter drauf, und das ist noch keine Alternative zu einem j-link z.B. Abstürze, Häger oder geht gar nicht in abwechselder Reihenfolge. Sowohl in der CooCox-IDE als auch als Keil-Plugin. SWD ging garnicht, nur JTAG. Auf der anderen Seite ist die Intergration des j-link in die CooCox-IDE auch nicht besonders. Da wird bei einem Controller-Reset das gesamte j-link Modul neu in die Eclipse-Umgebung eingebunden. Das dauert so lange, dass man einfach keinen Spass daran haben kann. Die IDE zu benutzen um einfach mal eine woanders übersetzte elf-Datei zu debuggen geht auch nur krampfhaft. Und wass bringen mir die vielen Libs die mann dazu klicken kann, wenn die Libs nichts taugen? DS18B20 z.B. ist ausschließlich über delay-Schleifen gemacht. Den ständigen Ntzwerkzugriffen nach China traue ich irgendwie auch nicht über den Weg.
Ich habe manuell Eclipse mit dem CDT Master Plugin installiert, dazu Codesourcery GCC Compiler und den J-Link GDB Server und das klappt sehr gut und ist richtig schnell. Um das Discovery mit dem eingebauten ST-Link zu nutzen muss ich den Atollic GDB Server nutzen, ist deutlich langsamer, aber klappt auch zufriedenstellend. Diese Konfiguration kann ich empfehlen, ich nutze die schon seit mehreren Jahren, und hat keine Codebegrenzung. Coocox gefiel mir nicht so gut, da ich im makefile / Linkerscript nicht so frei war wie ich es wollte. Ich muss für Bootloader usw. einige Speicherbereiche anlegen, das ging damals mit Coocox nicht wirklich. Mit dem GCC/makefile/Linkerscript bin ich sehr zufrieden. Es braucht natürlich auch etwas Zeit da durch zu steigen und zu verstehen, dafür hat man schlussendlich viel mehr Möglichkeiten und hat alles im Griff was wie übersetzt wird.
temp schrieb: > Mit den darauf > verbauten st-link Adaptern geht das Debuggen ganz gut. A Hallo an die Experten in dem Zusammenhang hätte ich mal eine Frage zum Discovery (bin gerade beim ersten Anschluß). Habe die lite-Version von Keil uVision 4.60 und bekomme keine Verbindung zum Board hin! Im Win7 Gerätemanager ist der "ST Micro... STLink dongle" installiert, für den Target-Driver der ST-Link Debugger eingestellt. Nun wollte ich mal das Firmware Update 1.1 machen aber da kommt nur die Meldung "Could not load file ... Debugger aborted". Also ich bin drauf und dran den Kritikern hier recht zu geben, daß da hab ich aber via ISP und PDI beim AVR sehr viel schneller eine Verbindung bekommen :-( Robert
Wer hat dir denn auch Keil empfohlen? Keil ist da etwas umständlich. Du musst "Programming Algorithm" von Hand hinzufügen. Sie Anhang.
Markus Müller schrieb: > Es braucht > natürlich auch etwas Zeit da durch zu steigen und zu verstehen, dafür > hat man schlussendlich viel mehr Möglichkeiten und hat alles im Griff > was wie übersetzt wird. Braucht man "Viel mehr Möglichkeiten" für Millionen kleinerer Controller-Apps wirklich? Ist die "etwas Zeit da durch zu steigen" wirklich sinnvoll investiert? Machen die "Viel mehr Möglichkeiten" nicht auch alles unnötig kompliziert? Der kleine Tiny der mir die Arbeitsbeleuchtung bei Abwesenheit zeitgesteuert wieder abschaltet zum Beispiel. Kleinst SMD+Transistor+winziges ASM Programm. Das mit ARM,Keil & Co.- eine Gruselvorstellung.
Golem schrieb: > Das mit ARM,Keil & Co.- eine > Gruselvorstellung. So ein Quatsch, mehr fällt mir dazu nicht ein!
Golem schrieb: > Markus Müller schrieb: >> Es braucht >> natürlich auch etwas Zeit da durch zu steigen und zu verstehen, dafür >> hat man schlussendlich viel mehr Möglichkeiten und hat alles im Griff >> was wie übersetzt wird. > > Braucht man "Viel mehr Möglichkeiten" für Millionen kleinerer > Controller-Apps wirklich? Ist die "etwas Zeit da durch zu steigen" > wirklich sinnvoll investiert? Machen die "Viel mehr Möglichkeiten" nicht > auch alles unnötig kompliziert? Wenn Du die AVR-Funktionalität auf den STM32 abbildest, dann steigt die Komplexität eigentlich gar nicht - nur der Overhead ist etwas größer. > Der kleine Tiny der mir die Arbeitsbeleuchtung bei Abwesenheit > zeitgesteuert wieder abschaltet zum Beispiel. Kleinst > SMD+Transistor+winziges ASM Programm. Das mit ARM,Keil & Co.- eine > Gruselvorstellung. Vor vier Monaten hätte ich vermutlich dasselbe geschrieben - am Anfang überwältigen einen die vielfältigen Möglichkeiten einfach. Aber wenn man sich wirklich Schritt für Schritt einarbeitet, ist das alles plötzlich gar nicht mehr so komplex. Heute würde ich sagen: "Komm, mache ich Dir eben." :-) Diese Zeit zur Einarbeitung musst Du Dir geben. Wenn Du mit den AVRs zufrieden bist und sie für Deine Anwendungen reichen: wunderbar! Dann ist es wirklich unnötig, auf ARM umzusteigen. Bei anderen (mir bspw.) reicht die Leistung jetzt eben nicht mehr - und da ich nicht gerne in zwei Architekturen parallel fit sein möchte, setze ich in Zukunft komplett auf STM32. Lieber eine Architektur wirklich verstehen und deren Macken kennen, als vier oder fünf nur halbwegs. Dass man einen STM32 mit einer Zeitsteuerung nicht einmal ansatzweise ausreizt, ist klar. Das ist aber der Lauf der Dinge. 32-Bitter kosten mittlerweile praktisch genauso viel wie die 8-Bitter. Da ist es irgendwann egal, ob der 99% der Zeit die Daumen dreht und man nur 5% der Hardware überhaupt verwendet. Chris D.
>Da ist es irgendwann egal, ob der 99% der Zeit die Daumen dreht und man >nur 5% der Hardware überhaupt verwendet. Daher kann man bei den ARM's die einzelen Peripherie Module schön deaktivieren und spart somit viel Strom. Auch kann man den mit nur wenigen MHz ohne PLL laufen lassen, denn die frisst auch den einen oder anderen mA weniger.
Richtig, Beispiel: [http://www.mikrocontroller.net/articles/EFM32 EFM32] von Energy Micro: Mit Hilfe der CMU (Clock Management Unit) kann man die Peripherie ein oder ausschalten, bzw. mit den Takt versorgen, der benötigt wird. Die ARM CMSIS Libraries helfen die Komplexität auf das Wesentliche zu beschränken. Viele ARM Cortex MCU-Hersteller verwenden diese. Die CPU-nahe Lib ist daher perfekt, wenn man von einem Hersteller zum anderen wechselt. Wenn die Hersteller CMSIS auch für die Peripherie-Lib verwenden, wie die EFM32Lib für den EFM32, dann ist es auch einfacher bzgl. Peripherie zu wechseln. Viel Spaß mit dem nächsten ARM Cortex M Projekt! TK
Wilhelm Ferkes schrieb: > Gerhard O. schrieb: > >> Hallo Wilhelm, >> >> Ich arbeite mich z. Zt. in den C8051F580 ein und der hat schon alle >> wichtige Peripherien in ausführlicher Ausstattung. Der eingebaute CAN >> Bus Controller scheint auch vieles ohne CPU Mitarbeit zu erledigen. >> >> Irgendwie finde ich dem MCU ganz gut konzipiert. Auch gibt es nur drei >> Minor ERRATA. Viele andere MCU haben eher voluminöse ERRATA Buechlein;-) > > ERRATA heißen heute auch schon wieder anders, wenn ich das richtig > vernahm. Das ist mir neu;-) > >> Naja, für mich ist dieser MCU noch ganz neu. Muss mal sehen wie viele >> Zähne ich mir dabei ausbeissen werde... (Obwohl der Vergleich hinkt, >> schlimmer als ein STM32 kann der bestimmt nicht sein und mit denen komme >> ich gut zurecht). >> >> mfg, >> Gerhard > > Die modernen SiLabs-Derivate haben allerdings mit dem echten 8051 kaum > noch was zu tun. Es sind taktreduzierte MCU, die auch noch eine Pipeline > haben. Die Zyklen etwas anders, als beim UR-8051. Wenn man keine Rücksicht auf Legacy nehmen muss, dann macht es bestimmt nichts aus. > > Aber ich wünsche dir viel Erfolg damit. Wir wollen ja nicht alle mit > einem µC eine fertige Mondrakete bauen, sondern die Unzahl viel > einfacherer Dinge. Danke für die guten Wünsche. Bei der Wahl des 8051 Derivates ging es mir hauptsächlich darum eine MCU Ausstattung zu finden die möglichst vergleichbar zu ähnlichen PICs und AVRs war, die ich sonst verwende. Ich möchte ein existierendes PIC Projekt auf den C8051 zu portieren. Deshalb gefällt mir der F58X Zweig sehr gut weil da alles an Peripherien und RAM vorhanden ist, die mein Projekt benötigt. Sonst habe ich noch einen AT89C8051RC2 herumliegen, der sieht auch erfolgversprechend aus. Gerhard
Gerhard O. schrieb: > Ich möchte ein existierendes PIC Projekt auf den C8051 zu portieren. Ich begann mal, ein reines Assembler-Projekt für den Standard-8051 zu beliebigen Plattformen zu portieren. Das ist aber noch eine Baustelle. Der Weg führt vom reinen Assembler zu C, und an einigen kniffligen Stellen mußte ich tatsächlich aus dem Assemblercode von Hand ein Flußdiagramm zeichnen, um es nach C zu überführen. Aber, es geht.
Hier ein kleiner Erfahrungsbericht mit dem STM32 von mir: Ich werkle seit letzten November im Betrieb an einem Projekt mit dem STM32F103. Zum Lernen mit einer Olimex-P103 Bord arbeitete ich anfangs mit der damaligen unbegrenzten Atollic Entwicklungsumgebung und für das Projekt stieg ich später im Betrieb auf IAR-EWARM um weil der in der Firma offiziell verwendet wird. Vorher arbeitete ich hauptsächlich mit 18/24/33er PICs und einigen AVRs. Nach einer etwas gewöhnungsbedürftigen Einarbeitungszeit auf die Besonderheiten der Welt der STM32s finde ich dass man ganz gut damit arbeiten kann. Wenn man mal alles richtig eingestellt hat und möglichst wiederverwendbaren Code schreibt, dann kann man ohne größeren Arbeitsaufwand vieles in neuen Projekte wiederverwenden. Den Startup Code kann man getrost den Einstellungen der Entwicklungsumgebung überlassen und sich auf das übrige konzentrieren. Es ist auch nutzbringend wenn man anfangs mit der CMSIS und ST-Peripheral Library arbeitet. Später kann man sich das alles auf einfachere Art stricken wie man es von anderen MCU Projekten gewöhnt ist. Das einzige was man auf alle Fälle (immer) tun sollte, vor dem H.W. und Bord Design sich die ERRATA gründlich durchlesen damit man nicht später unangenehme Überraschungen hat. Z.B. wenn man beim F103 USART1 die RTS/CTS Funktion braucht muss man wegen eines Fehlers in der MCU Peripherie die CAN Bus Pins remappen. Wenn man also da nicht aufpasst und die Original CAN Bus Pins verwenden will, kriegt man später beim Testen der Schaltung und FW leicht einen roten Kopf;-) Abschließend bin ich der Meinung dass, wen man schon etwas Erfahrung mit anderen Mikros hat, ohne Angst auf die ARM7 Typen umsteigen kann. Man darf sich halt nicht entmutigen lassen wenn man ab und zu die Tücken der neuen Welt kennen lernt. Dann muss man gründlich lernen und lesen und zähe sein. Am Ende geht dann doch alles. Bis jetzt habe ich alles noch zum Laufen gebracht. mfg, Gerhard
Ja ja, die Dinge zum Laufen zu bringen kann auch ein ehrgeiziges Ziel sein :) Schade um die Zeit. Wem dieser Thread noch nicht langt einen Eindruck von der aufgeblasenen Komplexität der ARM SW Entwicklung zu bekommen dem empfehle ich die Lektüre http://www.mikrocontroller.net/articles/STM32F4-Discovery ,die den beschwerlichen Weg anhand konkreter Hardware beschreibt. Abenteuerlich, ein Wahnsinn, welche Umstände es braucht um allein eine LED zum blinken zu bewegen... Nee nee, die 8 Bitter sterben schon so schnell nicht aus!
Je nach Entwicklungsumgebung ist es etwas mehr Aufwand die Dateien alle hin zu bekommen. Unter der Eclipse Umgebung ist in der Tat "Handarbeit". Damit der Einstieg leichter fällt habe ich hier ein Blink-Led DEMO in diesem Artikel: STM32 Eclipse Installation für den STM32F103. EIn Demo für den F4 habe ich auch, aber nicht fertig.
Ist das echt dein Ernst? Bislang kann ich kaum zusätzliche Komplexität sehen. Im Gegenteil zeigt das Beispiel im Artikel, dass die Schritte zum Pinwackeln im Grunde die Gleichen sind, auch wenn die Bezeichner anders gewählt sind. Ich sehe nur viel Argumentation über Geschmäcke. Weswegen der Thread so lang geworden ist. Dass man sich in jede neue uc Familie einarbeiten muss sollte selbstverständlich sein und gilt auch innerhalb des gleichen Herstellers/Technologie. Die Frage hier also ist eher, ist man offen, neugierig lernbereit für Neues, oder reicht einem (pragmatisch) was man kennt.
Golem schrieb: > Ja ja, die Dinge zum Laufen zu bringen kann auch ein ehrgeiziges Ziel > sein :) Schade um die Zeit. Wem dieser Thread noch nicht langt einen > Eindruck von der aufgeblasenen Komplexität der ARM SW Entwicklung zu > bekommen dem empfehle ich die Lektüre > http://www.mikrocontroller.net/articles/STM32F4-Discovery ,die den > beschwerlichen Weg anhand konkreter Hardware beschreibt. 1. zeigt dieser Artikel die Einrichtung der kompletten IDE und hat mit der STM-Programmierung außer dem kleinen Beispiel am Ende praktisch nichts zu tun. 2. habe ich genau mit diesem Artikel in weniger als zwei Stunden die IDE eingerichtet und konnte loslegen. Kompliziert ist nun wirklich anders. > Abenteuerlich, > ein Wahnsinn, welche Umstände es braucht um allein eine LED zum blinken > zu bewegen... Denselben Artikel kannst Du genauso für die Einrichtung von Eclipse für den AVR verwenden. Die "Komplexität" ist praktishc identisch. Denn: komplex ist da nicht der STM32 sondern Eclipse. > Nee nee, die 8 Bitter sterben schon so schnell nicht aus! Wer sie weiter verwenden möchte, darf das gerne tun. Dann aber auch bitte nicht über Dinge reden, die man offenbar selbst nicht kennt und in die man sich nicht einarbeiten möchte. Chris D. Edit: Ich sehe gerade, dass es sich beim letzten Golem-Beitrag mal wieder um eine multiple Persönlichkeit handelt - also Troll. Der Gute hat mit dem Golem weiter oben nichts zu tun. Glückwunsch - bin drauf reingefallen :-) Bitte nicht weiter darauf eingehen.
Chris D. schrieb: > 1. zeigt dieser Artikel die Einrichtung der kompletten IDE und hat mit > der STM-Programmierung außer dem kleinen Beispiel am Ende praktisch > nichts zu tun. > > 2. habe ich genau mit diesem Artikel in weniger als zwei Stunden die IDE > eingerichtet und konnte loslegen. > > Kompliziert ist nun wirklich anders. Chris, auch wenn du jemand anderen ansprachst: Sagtest du nicht mal, du wärst von Haus aus Informatiker? Nicht E-Techniker, wie ich? Ist es da nicht ein wenig einfacher? OK, ich richtete mir ja auch mal den SDCC für den 8051-er ein, der läuft ja auch nicht von selbst los. Nur die nackten Ausführungsprogramme für die Kommandozeile, und Libraries. Man muß sich auch noch irgendwo eine Bedienoberfläche suchen, und ein Batch-File machen, was die Quelldateien assembliert bzw. compiliert. Das klappte aber vorzüglich. Hier gab es mal einen Thread, wo jemand nicht mit dem SDCC klar kam. Da mußte ich mich aber selbst auch viele Tage mit befassen, war gelegentlich etwas säuerlich. Da kann ich aber jetzt selbst hier und da mal einen Rat geben. Von GCC und Make habe ich wiederum überhaupt keine Ahnung. Bei kleineren µC hat man mit sowas auch selten bis gar nicht zu tun. Die Komplexitätsunterschiede zwischen SDCC und den Tools, die ich für das Discovery-Board brauche, kann ich nicht einschätzen. Die Beiträge von Leuten, die es nicht manierlich hin bekamen, schreckten mich aus diesem Grunde aber auch etwas ab. Wenn es so wäre wie beim SDCC, hervorragend, damit könnte ich gut leben. Bestellt habe ich immer noch nicht, aber das kommt jetzt auf einen Tag gar nicht so genau an. Besonders nicht bei mir, der keine Entwicklung mit Termindruck hat. Vor dem STM32F4 selbst habe ich keine Panik, kann auch nicht sehr viel komplexer sein, als ein LPC2000.
Es ist nicht anders wie beim SDCC. Die Toolchain beim 32F4 ist im einfachsten Fall so simpel wie beim SDCC. GCC .. kompiliert .c Datei in Objectfile .o GCC .. linked ein oder mehrere .o Dateien in ein .bin Dazu gibt es ein Tool von ST mit dem man die Datei flashen kann. Das mit dem Makefile ist kein Muss. Es erleichtert nur die Sache wenn man mal viele .c Dateien hat. Weil es guckt halt was sich geändert hat und kompiliert nur was notwendig ist. Aber um all das braucht man sich nicht kümmern wenn man das kostenlose CooCox verwendet. Man sagt einfach EINMAL wo der GCC auf der Festplatte ist. Ab da langt ein Klick und es kompiliert. Ein weiterer klick lädt das Binary in den F4. Es ist sooo simpel! Warum wird hier immer so ein Drama daraus gemacht?
Golem schrieb: > Soooo simpel? Selten soooo gelacht :) Glaube ich nicht. Denn dann müsstest Du ständig lachen :-) Thomas bringt das schon gut auf den Punkt: Die Einrichtung der kompletten Toolchain benötigt keine zwei Stunden. Man hat für die Denkfaulen (wie mich) sogar eine Schritt-für-Schritt-Anleitung geschrieben. Wer schon bei solchen Dingen, bei denen man nicht einmal selbst zu Ergebnissen kommen sondern nur lesen/ausführen muss, scheitert - für den sind neue Controllerfamilien nichts. Der hat von diesen dann aber auch keinerlei Ahnung. Chris D.
Chris D. schrieb: > Wer schon bei solchen Dingen, bei denen man nicht einmal selbst zu > Ergebnissen kommen sondern nur lesen/ausführen muss, scheitert - für den > sind neue Controllerfamilien nichts. Der Meinung bin ich auch. Die Einrichtung einer neuen IDE ist teil der Einarbeitungszeit, die man eben hat beim Umstieg auf neue Prozessoren. Der Witz ist, dass dieser Anteil (die Einrichtung der IDE) nur ein kleiner Teil der gesamten Umstiegsarbeit ist. Wenn man diesen schon nicht überwinden kann, kann man es auch gleich sein lassen.
Hi Chris, erstmal Kompliment daß Ihr ARMen Euch solche Mühe gebt eine Hilfestellung zum Einstieg zu geben! Aber jeder Versuch die ARMs nur als anders und nicht als komplizierter als z.B. unsere lieben AVRs darzustellen sind einfach nur lächerlich. Vermutlich würde ich das nach Monaten der Einarbeitung aber auch nicht zugeben/eingestehen wollen :) Können wir uns nicht darauf einigen, daß man die ARMs erst dann einsetzt wenn deren Leistung/Features WIRKLICH gebraucht werden? Ganz davon abgesehen, daß dem Markt der ARM Programmiertools noch eine Apfelfirma fehlt.
Golem schrieb: > Hi Chris, erstmal Kompliment daß Ihr ARMen Euch solche Mühe gebt eine > Hilfestellung zum Einstieg zu geben! Aber jeder Versuch die ARMs nur als > anders und nicht als komplizierter als z.B. unsere lieben AVRs > darzustellen sind einfach nur lächerlich. Wer tut denn sowas? Natürlich sind die komplexer. Aber das ist doch kein Nachteil sondern eher eine Notwendigkeit, wenn der kleine AVR nicht mehr ausreicht! > Vermutlich würde ich das nach > Monaten der Einarbeitung aber auch nicht zugeben/eingestehen wollen :) > Können wir uns nicht darauf einigen, daß man die ARMs erst dann einsetzt > wenn deren Leistung/Features WIRKLICH gebraucht werden? Ja natürlich. Nur was du übersiehst ist: Zu Leistung/Features zählt auch - bereits gemachte Erfahrungen - Preis - Verfügbarkeit - ... andere nichttechnische Gründe Das heißt, jemand, der viel mit ARMs zu tun hat, wird sich einen Dreck darum scheren einen AVR zu benutzen, nur weil er den ARM nicht auslasten kann mit einer Anwendung. Auf der anderen Seite kann man auch zu den ARMs wechseln, wenn man für ein kommerzielles Produkt einen möglichst niedrigen Preis haben will, obwohl ein AVR den Job auch machen würde. Es ist eben alle eine Abwägungssache und zwar nicht nur aus technischer Sicht! > Ganz davon > abgesehen, daß dem Markt der ARM Programmiertools noch eine Apfelfirma > fehlt. Das glaube ich absolut nicht. Eine schnelle Suche nach OpenOCD + MACOSX gibt ein paar vielversprechende Ergebnisse.
Simon K. schrieb: > Die Einrichtung einer neuen IDE ist teil der > Einarbeitungszeit, die man eben hat beim Umstieg auf neue Prozessoren. > Der Witz ist, dass dieser Anteil (die Einrichtung der IDE) nur ein > kleiner Teil der gesamten Umstiegsarbeit ist. Eigentlich ist das die Hauptarbeit beim Umstieg. Weil was bleibt dann sonst noch übrig? Register lesen und schreiben ? ja gut bei dem einen µC ist es ein Register bei dem nächsten sind es getrennte Register. Ein Blick ins Datenblatt und gut ist es auch schon. Die Peripherie Bausteine aktivieren ? zb Uart oder Interrupthandler?. Auch da ein Blick ins Datenblatt und die Register mit den passenden Werte füllen. und fertig. Der Rest der Programmlogik ? Dem Rest ist es völlig egal auf welchem µC das ganze läuft. Ist der Code auch nur halbwegs gut geschrieben, sind die Änderungen beim Portieren von einem µC zum nächsten minimal bis Null.
Ralph schrieb: > Simon K. schrieb: >> Die Einrichtung einer neuen IDE ist teil der >> Einarbeitungszeit, die man eben hat beim Umstieg auf neue Prozessoren. >> Der Witz ist, dass dieser Anteil (die Einrichtung der IDE) nur ein >> kleiner Teil der gesamten Umstiegsarbeit ist. > > Eigentlich ist das die Hauptarbeit beim Umstieg. Sehe ich nicht so. > Weil was bleibt dann sonst noch übrig? Hast du dir mal die ganzen Peripherals vom ARM in ihrer Komplexität angeschaut? Da gibt es pro Peripheral eine Vielzahl von Funktionsmodi. Bis man da mal durchgeblickt hat, dauert es eben eine Weile. Bis man alle (oder viele) Peripherals durch hat, braucht man sicherlich mehr als ein paar Stunden zur Einrichtung der IDE. > Dem Rest ist es völlig egal auf welchem µC das ganze läuft. > Ist der Code auch nur halbwegs gut geschrieben, sind die Änderungen beim > Portieren von einem µC zum nächsten minimal bis Null. Das ist schlicht und einfach Unsinn, da verschieden Mikrocontroller nicht den gleichen Umfang an Peripherals haben bzw. die Peripherals untereinander nicht kompatibel sind. Da noch eine Abstraktionsebene einfügen zu wollen ist Overkill und nur mit ner Menge Aufwand zu realisieren, wie man an CMSIS und z.B. STM32 StdPeriph Library sieht.
Simon K. schrieb: > Natürlich sind die komplexer. Na also. Mehr wollte ich nicht hören. Komplexer, komplizierter und umständlicher- wenn es nämlich um die Millionen Anwendungen geht die ein 8 Bitter genauso bewältigt. Simon K. schrieb: > Auf der anderen Seite kann man auch zu den ARMs wechseln, wenn man für > ein kommerzielles Produkt einen möglichst niedrigen Preis haben will, Ich hatte doch schon gesagt daß im industrieellen Umfeld die Sache anders aussehen kann.
Simon K. schrieb: > Hast du dir mal die ganzen Peripherals vom ARM in ihrer Komplexität > angeschaut? Da gibt es pro Peripheral eine Vielzahl von Funktionsmodi. Eine in meinen Augen ungute Entwicklung. Die Hersteller wollen mit dieser Flexibilität sicher die Einsatzmöglichkeiten maximieren, machen damit aber auf der anderen Seite die Software unnötig kompliziert und fehleranfällig. Ob das alles immer zielführend ist? Ich denke weniger ist hier oft mehr.
Nö, höhere Flexibilität ist auch für einen Hobbyisten wie mich ein Segen. Weil man sich auf eine Familie einschiessen kann und dann ALLES damit abwickeln. Aber die Diskussion ist jedenfalls müßig, keiner kann den anderen überzeugen. Der einzige Nutzen davon ist für gegenwärtige und künftige Leser des Beitrag. Sonst hätte ich mich von vornherein da raus gehalten. Gegen stures verhalten ist kein Kraut gewachsen. Wenn man sich gegen jede technische Entwicklung sträubt, dann verwenden die vermutlich auch noch einen PC-XT ohne Festplatte mit DOS 2.11.
Golem schrieb: > Simon K. schrieb: >> Hast du dir mal die ganzen Peripherals vom ARM in ihrer Komplexität >> angeschaut? Da gibt es pro Peripheral eine Vielzahl von Funktionsmodi. > > Eine in meinen Augen ungute Entwicklung. Die Hersteller wollen mit > dieser Flexibilität sicher die Einsatzmöglichkeiten maximieren, machen > damit aber auf der anderen Seite die Software unnötig kompliziert und > fehleranfällig. Ob das alles immer zielführend ist? Ich denke weniger > ist hier oft mehr. Empfinde ich nicht so. Die Zeiten ändern sich - heutzutage sind die Chipkosten fast identisch, egal ob da nun drei oder 14 Timer sitzen. Da packt man drauf, was geht. Und der Vorteil ist: man kann einen Typ für fast alles einsetzen, muss sich also nicht durch zwei Dutzend Datenblätter lesen, weil je nach Anwendung der eine oder andere Chip gewählt werden muss. Es zwingt einen ja niemand, bspw. DMA einzusetzen, wenn man das nicht möchte. Bei den STM32 musst Du nur die Module einschalten, die Du auch wirklich benötigst. Und wenn man das so handhabt, dann ist bspw. das Blinken einer LED nicht komplexer als beim AVR. Dazu schaltet man nur ein einziges Modul ein (GPIO), initialisiert genau wie beim AVR die entsprechenden Pins und schaltet diese in einer Zeitschleife an und aus. Der Vorgang ist von der Komplexität der Vorgänge her also genau derselbe. Ich möchte Dir Deine AVRs nicht verleiden - wir arbeiten ja auch noch damit :-) Aber zu uns: wir arbeiten zu wenig mit Mikrocontrollern, als dass wir zwei Linien im Auge behalten könnten. Wenn man bspw. auch mal ein, zwei Monate nichts mit "seinem" Controller macht, dann benötigt man wieder etwas Zeit, um sich einzuarbeiten. Bei zwei Architekturen wäre der Aufwand noch größer - bei keinerlei Zusatznutzen für uns: denn die STM32 können ja alles, was die AVRs können - und eben erheblich mehr. Wenn ich für 50 Cent mehr einen 32-Bitter haben kann, dann fallen die AVRs hier eben hinten runter. Und deswegen werden wir hier eben komplett auf ARM umsteigen und - wenn wir hier soweit fit sind - keine AVRs mehr einsetzen. Das Bessere ist eben der Feind des Guten. Wenn für Dich die AVRs ausreichen, ist das doch ok. Wichtig ist immer nur: löst die Familie die AUfgaben, die ich habe oder nicht? Wenn uns die AVRs reichen würden, würde ich den Teufel tun, auf STM32 umzusteigen. Wobei mir die Verfügbarkeit nur durch Atmel schon gestört hat - bei ARM kann ich zumindest in erträglicher Zeit auf andere Hersteller umsteigen, wenn ich mich an die Bibliotheken halte bzw. wir uns jetzt ein halbwegs brauchbares HAL mit sauberen Schnittstellen aufbauen. Chris D.
Chris D. schrieb: > Wobei mir die Verfügbarkeit nur durch Atmel schon gestört hat - bei ARM > kann ich zumindest in erträglicher Zeit auf andere Hersteller umsteigen, Du willst provozieren? Na gut. In Deiner Schaltung läuft ein STM32F4x7 und dieser ist nicht lieferbar. Auf welchen gleichwertigen Typen eines anderen Herstellers würdest Du denn umsteigen und wie lange wirst Du dafür brauchen? :-) Wenn man sich auf einen µC festgelegt hat, ist man erst einmal von dessen Hersteller abhängig, egal welcher es ist. Das entscheidene daran ist nicht der verwendete Kern (ARM, RX, SH, ...) sondern die Peripherie, ohne die überhaupt nichts läuft! Den C-Quelltext anzupassen ist dagegen eher eine Kleinigkeit.
m.n. schrieb: > Chris D. schrieb: >> Wobei mir die Verfügbarkeit nur durch Atmel schon gestört hat - bei ARM >> kann ich zumindest in erträglicher Zeit auf andere Hersteller umsteigen, > > Du willst provozieren? Na gut. Nicht wirklich ... > In Deiner Schaltung läuft ein STM32F4x7 und dieser ist nicht lieferbar. > Auf welchen gleichwertigen Typen eines anderen Herstellers würdest Du > denn umsteigen und wie lange wirst Du dafür brauchen? :-) Wenn wir unser HAL so aufbauen können, wie ich es mir vorstelle, dann vielleicht ein bis zwei Wochen. > Wenn man sich auf einen µC festgelegt hat, ist man erst einmal von > dessen Hersteller abhängig, egal welcher es ist. Das entscheidene daran > ist nicht der verwendete Kern (ARM, RX, SH, ...) sondern die Peripherie, > ohne die überhaupt nichts läuft! Deswegen schrieb ich ja, dass wir von Anfang an ein HAL aufbauen werden, um die Anpassungen so gering wie möglich zu halten. Beim AVR damals hatte ich das (leider) versäumt. Passiert mir aber nicht nochmal. Mit der ST-Bibliothek hat man mMn schon eine ganz ordentliche Abstraktionsebene, die man nur noch verfeinern muss. Wenn ich mir bspw. die Stellaris M4 von TI ansehe, dann müsste ich unsere Programme bisher nur wenig ändern (sind zugegebenermaßen natürlich noch nicht sooo komplex). Es geht also schon. Bei der integrierten FPU und dem DSP wäre gar keine Änderung notwendig. Dass eine Umstellung ärgerlich und Arbeit ist, ist keine Frage :-) Aber sie ist zumindest in erträglicher Zeit machbar. Chris D. P.S.: Es ist aber auch nicht so, dass wir sofort auf dem Trockenen sitzen würden. Wir haben hier immer so 50 Chips vorrätig, mit denen wir dann schon ein bis zwei Monate hinkommen. Lagerhaltung ist also durchaus sinnvoll :-) Der Preisverfall kratzt uns wenig, da wir (gottseidank) nicht auf den Euro achten müssen. Die Position ist also natürlich komfortabler als bei anderen, die ihr Lager quasi auf der Straße haben. Aber da sag ich dann: selbst schuld.
So eine HAL ist sehr hilfreich, wenn man mal wechseln muss. Benötigt man hohe Stückzahlen, kann die Anpassung auf einen anderen Controller sogar bei voller Verfügbarkeit sinnvoll sein. Einfach eine Kostenfrage. Übrigens Kosten, - die werden bei den AVR explodieren. Weil die Autoindustrie die nicht mehr einsetzt. Private gibt es nicht ausreichend, vorallem wenn die auch abwandern.
Chris D. schrieb: > Wenn wir unser HAL so aufbauen können, wie ich es mir vorstelle, dann > vielleicht ein bis zwei Wochen. Die Sache mit HAL ist eher soetwas wie ein reduziertes "HALLO WELT" auf einem anderen µC anzuzeigen :-) Welcher andere µC inkl. Timer läuft denn mit 168MHz? Und welcher µC hat denn 196kRAM intern? Gleiches Pinout? Und, und, und, ... Oder ganz direkt: es gibt keinen Zweitlieferanten! Oder man beschränkt sich auf Grundfunktionen, die auch ein AVR leisten kann :-) Thomas Winkler schrieb: > Übrigens Kosten, - die werden bei den AVR explodieren. Weil die > Autoindustrie die nicht mehr einsetzt. Dann werden im Gegenzug die RXe wohl spottenbillig werden! Genug gelästert :-)
m.n. schrieb: > Chris D. schrieb: >> Wenn wir unser HAL so aufbauen können, wie ich es mir vorstelle, dann >> vielleicht ein bis zwei Wochen. > > Die Sache mit HAL ist eher soetwas wie ein reduziertes "HALLO WELT" auf > einem anderen µC anzuzeigen :-) Wenn man ein schlechtes HAL hat sicherlich :-) Aber unser wird da schon deutlich mehr können. > Welcher andere µC inkl. Timer läuft denn mit 168MHz? > Und welcher µC hat denn 196kRAM intern? Das reizen wir eh nicht aus, sind da also flexibel. Außerdem ist TI auch schon bei 150MHz. Bis auf Timeranpassungen (für die u.a. unser HAL zuständig sein wird) muss man also nichts unternehmen. > Gleiches Pinout? Das Pinout ist bei einem Familienwechsel mein geringstes Problem, zumal es da durchaus Möglichkeiten gibt, auf den Boards eine "Zwischenlage" mit einzuplanen (was wir auch tun). Also einfach ein kleines zweilagiges "Konvertierungs-PCB", das aufgelötet wird und die Pinbelegung anpasst. Das haben wir sogar schon für einige AVRs gemacht. Ist alles keine große Sache, wenn man da vorher dran denkt. > Oder ganz direkt: es gibt keinen Zweitlieferanten! > Oder man beschränkt sich auf Grundfunktionen, die auch ein AVR leisten > kann :-) Guter Scherz :-) Nein, AVRs, so gerne ich sie hatte, sind bei uns jetzt einfach an ihrer Grenze angekommen und fliegen raus. > Thomas Winkler schrieb: >> Übrigens Kosten, - die werden bei den AVR explodieren. Weil die >> Autoindustrie die nicht mehr einsetzt. > > Dann werden im Gegenzug die RXe wohl spottenbillig werden! > Genug gelästert :-) RX ist eben auch Monopolist. Noch ein Vorteil der ARM-Geschichte - die Preise sinken, weil man Chips mit ähnlicher Ausstattung, Rechenleistung und AUfbau eben auch von anderen Herstellern bekommt. Da kann sich keiner Ausreisser nach oben erlauben. Chris D.
Jeder der sein Hobby zum Beruf machen will (Job in einer entsprechenden Firma), der sollte sich ein wenig mit den ARM's beschäftigen. Da fällt dem zukünftigen Chef die Auswahl der Bewerber dann auch leichter.
Thomas Winkler schrieb: > Nö, höhere Flexibilität ist auch für einen Hobbyisten wie mich ein > Segen. Weil man sich auf eine Familie einschiessen kann und dann ALLES > damit abwickeln. Kann ich mit Xmega auch. Anstatt die Konfigurationsmöglichkeiten wie Unkraut sprießen zu lassen sollte die Entwicklung eher zu mehr Intelligenz in den Peripheriebausteinen gehen! Nehmen wir z.B. I2C. Es würde doch langen dem Baustein die nötigen Daten (Speed, Device Adresse, zu lesende, zu schreibende Bytes aus/in einen internen Bausteinbuffer) zu übergeben. Aber nein, ein extra Treiber wird für die Abwicklung nötig. Thomas Winkler schrieb: > Wenn man sich gegen > jede technische Entwicklung sträubt So ein Blödsinn. Nur sollte man sich nicht nerdmäßig von der ach so tollen Hardware blenden lassen m.n. schrieb: > Welcher andere µC inkl. Timer läuft denn mit 168MHz? ...sondern die realen Anforderungen im Auge behalten. Die Xmegas neuerer Bauart lassen sich übrigens auch schon auf 64 MHz hochtakten- aber diesen Speed werd ich mangels Multimediaanwendungen wohl nie brauchen. Die kauf ich viel billiger im Laden! Ich persönlich würde für einen AVR locker das Dreifache bezahlen wenn die SW-Entwicklung weiter überschaubar bleibt. Und sollte später wirklich mal alles auf ARM umschwenken hoffe ich, daß dann eine Apfelfirma daherkommt und die Hardware-Differenzen / Konfigurationsmöglichkeiten gekonnt in einem einfachen Programmiertool zusammenfaßt. iPadmäßig halt :) Hier wie dort wird es aber weiter Komplexitätsapostel geben die Kompliziertheit als Wert an sich betrachten, und sei es auch nur um sich jahrelang angesammeltes Fachwissen nicht so einfach entwerten zu lassen...
Moby schrieb: > Thomas Winkler schrieb: >> Nö, höhere Flexibilität ist auch für einen Hobbyisten wie mich ein >> Segen. Weil man sich auf eine Familie einschiessen kann und dann ALLES >> damit abwickeln. > > Kann ich mit Xmega auch. Natürlich geht das auch mit dem Xmega - immer im Rahmen der Möglichkeiten des entsprechenden Controllers. Irgendwann reicht es halt nicht mehr und dann muss man wechseln. Und wenn man dann schaut, welche Leistung man für dasselbe Geld erhält, dann spricht auch nichts dagegen, die neue Familie auch in kleineren Projekten einzusetzen. Wie schon weiter oben gesagt: ich würde nur ungern zwei Familien gleichzeitig pflegen. > Anstatt die Konfigurationsmöglichkeiten wie > Unkraut sprießen zu lassen sollte die Entwicklung eher zu mehr > Intelligenz in den Peripheriebausteinen gehen! Nehmen wir z.B. I2C. Es > würde doch langen dem Baustein die nötigen Daten (Speed, Device Adresse, > zu lesende, zu schreibende Bytes aus/in einen internen Bausteinbuffer) > zu übergeben. Aber nein, ein extra Treiber wird für die Abwicklung > nötig. Genau das hast Du bspw. beim STM32 schon fast erreicht. Du sagst der I2C mit einem Struct nur noch, dass sie mit der Adresse X und der Geschwindigkeit Y eine festgelegte Anzahl an Daten senden soll, das man dann auch noch per DMA erledigen lässt. Gleiches gilt für den Empfang: bei richtiger Adresse springt Deine I2S an und Deine DMA schaufelt die Daten dorthin, wo Du möchtest. Das alles geschieht vollautomatisch und ohne weitere Prozessorbelastung. Und am Ende kriegst Du noch Hinweise, ob alles geklappt hat bzw. dass empfangen wurde - wenn man möchte per Interrupt. Einfacher geht es kaum noch. > m.n. schrieb: >> Welcher andere µC inkl. Timer läuft denn mit 168MHz? > > ...sondern die realen Anforderungen im Auge behalten. Die Xmegas neuerer > Bauart lassen sich übrigens auch schon auf 64 MHz hochtakten- aber > diesen Speed werd ich mangels Multimediaanwendungen wohl nie brauchen. > Die kauf ich viel billiger im Laden! Naja, jeder hat andere Anforderungen an die Geschwindigkeit. Und: nicht jede Anwendung kann man im Laden kaufen (insbesondere nicht unsere ;-) Multimediaanwendungen sind nur ein sehr kleiner Teil der speicher- und rechenintensiven Anwendungen. > Ich persönlich würde für einen AVR locker das Dreifache bezahlen wenn > die SW-Entwicklung weiter überschaubar bleibt. Und sollte später > wirklich mal alles auf ARM umschwenken hoffe ich, daß dann eine > Apfelfirma daherkommt und die Hardware-Differenzen / > Konfigurationsmöglichkeiten gekonnt in einem einfachen Programmiertool > zusammenfaßt. iPadmäßig halt :) Das wird dann nur auf deren Produkte passen - eben apfelmäßig. Denn die werden kaum für andere entwickeln ;-) Aber das sind alles ungelegte Eier - lassen wir uns überraschen. Ich finde, ST hat mit der Bibliothek schon einen guten Schritt zur Vereinheitlichung zumindest bei ihren Produkten gemacht. Klar ist auch die nicht perfekt, aber es ist ein Anfang. > Hier wie dort wird es aber weiter > Komplexitätsapostel geben die Kompliziertheit als Wert an sich > betrachten, und sei es auch nur um sich jahrelang angesammeltes > Fachwissen nicht so einfach entwerten zu lassen... Ich bin eher für Einfachheit, daher: lieber nur einen Typ verwenden, den aber richtig. Ob das wie bei uns jetzt ARM wird oder bei Dir AVRs sind, ist ganz egal. Chris D.
Chris D. schrieb: > Ich finde, ST hat mit der Bibliothek schon einen guten Schritt zur > Vereinheitlichung zumindest bei ihren Produkten gemacht. Klar ist auch > die nicht perfekt, aber es ist ein Anfang. Das halte ich für ein Gerücht. Dann müssten ja Programme vom F1 auch auf dem F4 laufen...
Jörg B. schrieb: > Das halte ich für ein Gerücht. Dann müssten ja Programme vom F1 auch auf > dem F4 laufen... Wie ich hier vernahm, können die STM32F4 THUMB oder THUMB2, keinen ARM-Mode. Der LPC 2100/2200 konnte wiederum ARM und THUMB. Das sollte noch geklärt werden.
>Das halte ich für ein Gerücht. Dann müssten ja Programme vom F1 auch auf >dem F4 laufen... Das tun sie natürlich nicht. Programme für XMega laufen aber auch nicht auf ATMEga. Die Bibliotheken für STM32F4 und STM32F1 sind aber zum grössten Teil portabel. Es gibt größere Unterschiede z.B. beim DMA. Aber da ist ja auch die Hardware eine andere. Ein Umstieg von STM32F1 auf STM32F4 geht relativ schmerzfrei.
GPIO und Clock's sind noch anders, da haben die beim STM32F2/4 noch einige nette Erweiterungen hinzugefügt ;-) Der Rest (Timer, I2C, SPI usw.) sollten gleich sein. Dennoch ist die Umstellung recht leicht, habe ich schon einige male gemacht.
Es ist tatsächlich so, dass einige F1 sample codes fast unverändert am F4 laufen. Natürlich muss man sagen, die Pin Belegung ist teilweise anders, das muss man selbstverständlich anpassen. Der F4 hat einiges mehr (SDIO) und anders, solche Hardware abhängigen Sachen muss man immer anpassen. Auch zwischen zwei AVR.
Ich unterbreche die wissenschaftliche Diskusion:"Können Dinge, schwerer als Luft, von sich aus fliegen" nur ungern, dennoch bitte ich die Herrschaften, mal einen Blick aus dem Fenster zu wagen. Dort geht ein Bub' mit seinem Luftballon spazieren ...
Ein paar Zitate aus Goethes Faust: "Der Worte sind genug gewechselt, lasst mich auch endlich Taten sehen." Der Direktor, im Vorspiel auf dem Theater zum "Faust" "Es irrt der Mensch solang er strebt." Gott "Ich bin der Geist der stets verneint." Mephisto "Alles, was entsteht, ist wert, dass es zugrunde geht." Mephisto http://free.pages.at/hojager/wissen/redewendungen_d.htm
Der Chef zum Entwickler: "Der Worte sind genug gewechselt, lasst mich auch endlich Daten sehen." Peter
Golem schrieb: > Na also. Mehr wollte ich nicht hören. Komplexer, komplizierter und > umständlicher- wenn es nämlich um die Millionen Anwendungen geht die ein > 8 Bitter genauso bewältigt. Der Fehler liegt darin Komplexität und Umständlichkeit gleichzusetzen. Das ist nicht der Fall. Vereinachtes Beispiel: Wenn ich nen AVR mit einem Port und 8 IO Pins habe (angenommen in der Ausführung gibt es den) und wechsle auf einen Arm der nun zwei Ports mit je 8 Pins hat. Dann läuft das Orginalprogramm genauso auf dem Neuen. Mein Programm ist also genauso einfach gehalten wie vorher. Der AVR lässt sich genauso einfach/ nicht komplizierter wie vorher ansteuern. Dennoch ist der AVR komplexer (um genau einen Port) Wenn du also von Komplexität sprichst, dann trägt das nur dann zur Umständlichkeit bei, wenn du gezwungen bist diese Dinge zu nutzen. Konstanter Aufwand (Initiales Registersetzen) ist kein Aufwand. O(0) == O(1) Wenn du allerdings sowieso Features brauchst, die die Hardware vor dem Wechsel nicht unterstützt, dann macht eine Hardware, die dies für dich mit Optionen löst dein Problem nicht komplizierter, sondern im Gegenteil gar einfacher, in dem es dich nicht dazu zwingt Hilfsmittel, die nicht zur Programmlogik gehören in Software zu lösen.
Hast Du im Grundsätzlichen sehr schön erklärt, Maxx, wenn nur der verdammte Teufel sich nicht immer im ARM-Detail, der hochflexibel unübersichtlichen Hardware- ,Tool- und Librarylandschaft verstecken würde! Naja, den (in reizvoll neuer Hardware) auszutreiben mag vielleicht elementarer Bestandteil des Programmierspaßes sein. Aber ob es immer die viele Zeit lohnt, wenn es genausogut mit einem Update der alten Hardware geht (Mega->Xmega)? Das ist natürlich auch eine Frage persönlicher Interessen/Vorlieben. In meinen Augen sollte der Plattformwechsel ob des Aufwands schon zwingend sein. Durch mehr und nötige Performance, durch einfachere Programmierbarkeit, durch weitere Gründe. Alles nicht gegeben? Dann warten wir doch auf die übernächste HW Revolution! Die kommt bestimmt! Bis dahin investieren wir unsere kostbare Lebenszeit besser sinnvoller :)
Thomas Winkler schrieb: > Übrigens Kosten, - die werden bei den AVR explodieren. Weil die > Autoindustrie die nicht mehr einsetzt. Private gibt es nicht > ausreichend, vorallem wenn die auch abwandern. So ein Schwachsinn, AVR sind zum Teil bis 150°C spezifiziert und es kamen vor kurzem erst neue Automotive Qualifizierungen auf 125°C raus, zeig mir mal einen Cortex der 150°C Flash Technologie hat... Niedrige Stromaufnahme ist der Schlüssel um in der Automotive Industrie überhaupt als Hersteller in Betracht genommen zu werden, oder meinst Du wirklich jeder Sensor läuft da mit STM32 der >300uA/Mhz verbraucht, und im Sleep Mode nicht unter 1uA kommt... Erst kürzlich hat Atmel neue Tinys vorgestellt die in super-kleinen Package daherkommem, überall wo ein MEMS Sensor eingesetzt wird (hauptsächlich Mobiltelefone) wird ein kleiner Controller benötigt damit man den Baseband nicht mit diesen Dingen "belästigen" muß. In der Hausgerätetechnik werden immer noch Bauteile verwendet die 5.5V unterstützen. Das sind alles Massenmärkte für die AVR und da hat selbst ein 50Cent CortexM0 keinen Platz (zu viel Strom im PowerSave, zu starker Anstieg der Powerconsumption über den TempBereich, keine getrennte Busse, Interrupt Latency zu viele Cycles, langsamer wakeup)... das ist alles nur Marketing Gelaber
mal sehen, wann auch die Letzten bemerken, daß das "Amen" schon längst gesprochen wurde ------;
Mist. Watterott hat ausverkauft, Lagerbestand Null. Sonst hätte ich heute Discovery bestellt. ;-)
Jetzt hast Du zu lange gewartet ;-) Wer zu spät kommt, den bestraft das Leben.
Discovery F4: http://www.ebay.at/itm/STM32F4-Discovery-/251162019805?pt=Wissenschaftliche_Ger%C3%A4te&hash=item3a7a6c47dd
http://de.mouser.com/ProductDetail/STMicroelectronics/STM32F4DISCOVERY/?qs=sGAEpiMZZMutVogd4PRSvEN8XDBeCtgD ab 75 euro Versandkostenfrei - macht doch ne sammelbestellung.
Gibts ja teilweise schon ab 13 Euro... Das kann doch unmöglich kostendeckend sein! Die habens aber nötig, Ihr ARM Zeugs in den Markt zu drücken ?!
Also bei 13€ kann ich mir das noch kostendeckend vorstellen. Was würde denn mehr kosten? Allerdings gibt es noch günstigere Einstiegsboard (Stichwort Launchpad) die dann auch in der Menge fegrenzt sind. Finde das deutet nicht unbedingt auf "nötig haben" hin, sondern ein Bewusstsein für die DiY/Hobbyfraktion. Machen wir uns nichts vor. Einsteiger (Darunter viele Schüler) wollen es hier meist sehr preiswert.
Michael schrieb: > Gibts ja teilweise schon ab 13 Euro... Das kann doch unmöglich > kostendeckend sein! Die habens aber nötig, Ihr ARM Zeugs in den Markt zu > drücken ?! das nennt sich "Buying Marketshare" - das ist doch heute alles was zählt - zu jedem Preis Marktanteile gewinnen, ohne Rücksicht auf Verluste (siehe ST, trotz scheinbar so niedrigen Preise sind die trotzdem nicht in der Lage zu wirtschaften, so dass sie nun gar die Produktion kürzen müssen). Und dann wenn man den Markt mir Ramsch-Preisen aufgekauft hat erhöht man den Preis... im Analogen Bereich hat ST schon die Preise erhöht, von irgendwas muß man ja dann die nächste Innovation finanzieren
Markus schrieb: > Michael schrieb: >> Gibts ja teilweise schon ab 13 Euro... Das kann doch unmöglich >> kostendeckend sein! Die habens aber nötig, Ihr ARM Zeugs in den Markt zu >> drücken ?! Warum sollte das nicht kostendeckend sein? Wenn man sich überlegt, wieviel ST wohl an Produktionskosten für ihre eigenen Chips hat und was so auf dem Board ist, dann sollte das in den Stückzahlen locker für einen 10er machbar sein. Zumal ich nicht denke, dass bspw. Cirrus viel für z.B. den Audio-Codec verlangt. Vermutlich gibt es den sogar umsonst, weil sich Cirrus gar keine bessere Werbung für sich wünschen kann. Und TI springt auf denselben Zug auf :-) > das nennt sich "Buying Marketshare" - das ist doch heute alles was zählt > - zu jedem Preis Marktanteile gewinnen, ohne Rücksicht auf Verluste Ich denke nicht, dass sie damit Verluste machen. Gewinn aber auch nicht. Ich erwarte allerdings von einem Unternehmen, das mir seine Chips schmackhaft machen möchte, dass es die Entwicklungstools dafür entsprechend günstig zur Verfügung stellt und nicht nochmal abkassiert, damit ich überhaupt deren Chips programmieren "darf". ST macht letztendlich nur das, was Atmel erfolgreich praktiziert hat: preiswerte Entwicklungstools (und bei Atmel noch entsprechende Gehäuse) und Einstiegsmöglichkeiten. Das Board werden sich viele Studenten etc leisten - und das sorgt natürlich dafür, dass diese Chips später mit Vorliebe in der Entwicklung genommen werden. Ich würde es nicht anders machen. > (siehe ST, trotz scheinbar so niedrigen Preise sind die trotzdem nicht > in der Lage zu wirtschaften, so dass sie nun gar die Produktion kürzen > müssen). Das ist ein vollkommen normaler Vorgang im zyklischen Geschäft. > Und dann wenn man den Markt mir Ramsch-Preisen aufgekauft hat erhöht man > den Preis... im Analogen Bereich hat ST schon die Preise erhöht, von > irgendwas muß man ja dann die nächste Innovation finanzieren Auch das ist normal, funktioniert bei ARM aber nicht wirklich. Die Hürde für den Umstieg auf andere ARM-Hersteller, die Chips ähnlicher Leistungsklasse anbieten, ist dafür zu gering. Würde der Preis großartig anziehen, wechseln die Leute beim nächsten Projekt eben zu jemand anderem (und nehmen die IDE etc. mit). Chris D.
Hallo, hab zum STM32F4 Discovery gerade das hier entdeckt: http://shop.myavr.de/ARM-Produktlinie/mySTM32-Board-F4D,%20Bausatz.htm?sp=article.sp.php&artID=200075 da komm ich ja mit dem Discovery billiger hin wie bei nem MK2 Bausatz :-o ich glaub da steig ich auch mal von meinem myAVR auf einen myARM um ;-) Gruß
Als ich jetzt einem ein ST Discovery zum Start empfohlen habe, ist mir etwas negatives an dem Tipp aufgefallen. Das ist allerdings nicht die zu hohe Komplexität des ganzen, denn auf dem Teil werden schon fleissig neue kleine Dinge implementiert. Wenn die Person jetzt "nur" Hobbyist wäre, würde ich sagen toll! Das negative an dem ganzen ist, dass gar kein Background in der Basis aufgebaut wird wie man es eigentlich bräuchte meiner Meinung nach, wenn man später mit solchen Geräten Hardware ansteuern soll. Ich selbst habe mir ARM und Assembler noch nicht wirklich angeschaut, aber auf den AVRs ist doch immer wieder mal etwas inline Assembler im Code vorhanden, auch wenn ich das im Gegensatz zu meinem Chef meist noch versuche in C so zu Programmieren das mein wunsch assembling rauskommt, um einfach auch während der ganzen C Programmierung ein Gefühl dafür zu bekommen. In wichtigen Programmteilen schaue ich auch über das Assembler Listing, um uneffiziente Programmierung im Code aufzudecken. Mir als Anfänger passieren doch immer wieder uneffiziente Dinge, welche mir ohne diese Analyse nicht auffallen würden. Wichtig wird so etwas ja auch wenn eine neue Firmware im Vergleich zu dem was mal ursprünglich vorhanden war "riesen" groß geworden ist und man alles geben muss um es noch auf das Board zu bringen. Daher meine Frage: Gibt es ein gutes Assembler Tutorial für das Discovery? Welches so anfängerfreundlich ist wie das AVR Tutorial? Dabei geht es mir nicht darum, dass jemand selbst ohne Probleme ein hocheffizientes Assembler Programm schreiben kann, sondern Assembler eher lesen kann und ein Gefühl hat für die Dauer unterschiedlicher Operationen. Man sollte einfach schon einmal damit konfrontiert worden sein damit und keine scheu haben bei Problemen in diese Richtung zu schauen. Ich finde übrigens den RX (vom mal drüberschauen der Dokumentation) aber auch den AVR32 (kleine Programmcodeanpassungen) definitiv nicht schlecht im vergleich zu ARM, allerdings ist bei letzterem der Einstieg doch günstiger finde ich. Auch wenn gerade der AVR32 vom AVR Studio profitiert.
Ach Golem, nen bockiges Kind haben die meisten von uns hin und wieder daheim. Muss es auch hier sein? Danke für deine Einsicht (Ja ich bin ein Optimist ;-) ) @Tutorial, Die Tutorial beziehen sich ja nicht auf den Kern alleine, sondern Hersteller & Kern. So Findet man auch beim einfachen, weniger komplexen 8051er Tutorials auch eine Menge verscheidener, je nachdem mit welchem 51 man nun loslegen will. Für ARM gilt das Gleiche. Auf den entsprechenden Support-Foren des Herstellers zur Serie finden sich meist ausgezeichnete Tutorials. Sowie auf von privaten betriebenen dem ARM gewidmeten Seiten. Ausgezeichnet für jugendliche / junggeblieben Anfänger eignen sich zum Beispiel die vielen Tutorial zum ARM auf dem GBA inklusive der Peripherie dort. Assembler ist für ARM wirklich simpel. 14 Instruktionen. Splittet man "Data Processing" nochmal eigenständig auf dann sinds 29. Bei Thumb/Thumb2 wirds dann etwas stärker verfeinert, aber nicht schwer.
Der Unwissende schrieb: > Gibt es ein gutes Assembler Tutorial für das Discovery? Du meinst wohl ein Tutorial für ARM-Assembler. Muß mal suchen, nach Plättung meines Rechners wurden auch die Favoriten mit geplättet. Vielleicht hab ichs noch irgendwo. Auf jeden Fall Chinesen und Koreaner.
Falls jemand auf der Suche nach einem deutschen Tutorium ist. Ich finde dieses hier sehr hilfreich. http://diller-technologies.de/stm32_wide.html
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.