Hallo, ich spiele mit dem Gedanken, von der 8-Bit/8051-Welt in die 32-Bit/ARM-Welt zu wechseln. Ich lese mir auch hier grad die entsprechende "Wechsel"-Beiträge durch, bin aber ehrlich gesagt etwas erschlagen, einerseits von der Vielfalt der Möglichkeiten (sprich: Hersteller) und andererseits auch von den Aussagen (mal ist NxP einsteigerfreundlich, dann Luminary, dann ST, etc.). Jetzt bin ich eigentlich noch mehr verunsichert als vorher :( Vielleicht kann mir mal jemand bei der Auswahl hilfreich in die Seite treten. Was ich gerne hätte: - SingleSupply-Voltage - 5V-tolerante IOs - n.M.integrierter Bootloader (den man sich geschickterweise nicht zerschießen kann) - Debug-Möglichkeit (z.B.JTAG o.ä. -> welches Tool?) Ich möchte keine Betriebssysteme o.ä.drauf laufen lassen, im Prinzip möchte ich einerseits meine 8051-Schaltungen "ersetzen", aber andererseits sollte es schon etwas performanter sein. Soweit ich gesehen (und bis jetzt verstanden) habe, sollte ein ARM mit wesentlich weniger Befehlen in der Lage sein, dass gleiche zu realisieren wie ein 8051. Wie muss ich dazu die größere Befehlsbreite einer ARM-MCU in Relation setzen? In einen 64-kB 8051 bekomme ich ja eine größere Anzahl Befehle als in einen 64-kB ARM, aber der braucht ja weniger Befehle für die gleiche Aufgabe als der 8051 (je nach Aufgabe). Gibts da irgendeinen "Daumen"-Wert? Ich möchte zwar gerne günstige Bauteile einkaufen, aber auch vermeiden, dass der Speicher gleich voll ist, wenn's anfängt interessant zu werden :) Also es muss nicht highend sein, sollte aber andererseits auch nicht grad gleich an die Grenzen stoßen, wenn man beispielsweise eine LED-RGB-Matrix oder auch mal ein Farb-Display ansteuert. Und andersrum gesehen, es gibt ganz kleine putzige 8051er mit wenigen Pins und Speicher, aber auch relativ große und schnelle mit bis zu 100MHz und acht Ports. Diese Flexibilität würde ich gerne beibehalten. Wie ich gelesen habe, bieten einige Hersteller auch gleich komplette Bibliotheken an, sodass der Einstieg bzw. einfach die Applikationsprogrammierung an sich einfacher wird, was man wohl auch ins Auge fassen sollte. Und zu guter Letzt die Frage nach der IDE. Einige Hersteller bieten eigene an, andererseits gibt es wohl auch GCC/SDCC-Unterstützung. Andererseits muss die IDE ja dann geschickterweise auch das In-System-Debugging unterstützen, geht das denn mit den freien Compilern und IDEs? Momentan springe ich zwischen den Features, Hersteller-"Unterstützungen" ála Libraries und den Preisen von beispielsweise ST und Luminary hin und her, muss aber erst noch konkret filtern. Vielleicht könnt ihr mir trotzdem ein bisschen unter die Arme greifen... Ralf
Ralf schrieb: > Auge fassen sollte. Und zu guter Letzt die Frage nach der IDE. Einige > Hersteller bieten eigene an, Bei ARM? M.W. bietet das nur die Konkurrenz mit AVR32/PIC32. Die ARMen verlassen sich auf den gut bestückten Markt. Ansonsten eine Preisfrage. Eclipse/GCC/OpenOCD ist kostnix, aber etwas harzig bis es läuft. Atollic fehlt in der kostenlosen Version C++, was viele wohl verschmerzen können. Crossworks ist für nichtkommerziellen Einsatz recht günstig. Rest bei nichttrivialer Grösse teuer. > geschickterweise auch das In-System-Debugging unterstützen, geht das > denn mit den freien Compilern und IDEs? Klar geht das. Frei sind m.W. nur Eclipse/GCC/OpenOCD und Atollic. Was letzteres an Adaptern frisst verrät deren Webseite.
1. Core Ich habe mich auf den Cortex M3 konzentriert. Mit ARM7 würde ich nicht mehr anfangen, denn der M3 hat etliche Vorteile bezüglich Interrupt-Verarbeitung, Debugging, eine einheitlichere Architektur, bei der mehr Komponenten herstellerübergreifend standardisiert sind, etc etc. 2. Hersteller Ich würde mich hier nicht festlegen wollen. Die Tools sind überall die gleichen, der Kern ist überall der gleiche, die Systemperipherie ist überall identisch, einzig die Anwenderperipherie (SPI/I2C/UARTS/DMA/Ethernet/...) macht jeder Hersteller wie er will, und dafür gibts dann auch in der Regel passende Bibliotheken. 5V IOs sind out, 3.3V Single Supply die Regel. Einzig Toshiba hat Cortex M3 mit 5V. Zusätzliche Kernspannungen (1.2 oder 1.8V) findet man erst bei ARM9. 3. Debugging Die günstigen JTAG-Adapter basieren auf dem FTDI FT2232D (Full-Speed) oder FT2232H (Hi-Speed). Der JLINK ist sehr empfehlenswert - die neueren Versionen können auch SerialWire, die 2-Draht-Version von JTAG, die spezifisch für die Cortex-Serie ist. 4. Compiler Die besten Compiler kommen von ARM/Keil und IAR, aber die Vollversionen wirst Du nicht bezahlen können. fchk
Hallo, vielen Dank für eure Antworten. @prx: >> Einige Hersteller bieten eigene an, ... > Bei ARM? M.W. bietet das nur die Konkurrenz mit AVR32/PIC32. Die ARMen > verlassen sich auf den gut bestückten Markt. Ich habe murks geschrieben, sorry, eigentlich meinte ich, dass die Hersteller mit verschiedenen IDE-Anbietern zusammenarbeiten. > Ansonsten eine Preisfrage. Eclipse/GCC/OpenOCD ist kostnix, aber etwas > harzig bis es läuft. Atollic fehlt in der kostenlosen Version C++, was > viele wohl verschmerzen können. Crossworks ist für nichtkommerziellen > Einsatz recht günstig. Rest bei nichttrivialer Grösse teuer. Okay, danke, dass sind dann doch gleich mal ein paar weitere Stichwörter für die Suche :) @fchk: > 1. Core > Ich habe mich auf den Cortex M3 konzentriert. Mit ARM7 würde ich nicht > mehr anfangen, denn der M3 hat etliche Vorteile bezüglich ... Bezieht sich die Aussage auf die beiden von mir genannten Hersteller? Ich dachte, Cortex M3 wird von verschiedenen Herstellern angeboten, bin ich auf dem falschen Dampfer? Cortex M3 oder M0 wären so die beiden Cores gewesen, die ich mir zutraue, an ARM7 dachte ich eigentlich eh nicht. > 2. Hersteller > Ich würde mich hier nicht festlegen wollen. Die Tools sind überall die > gleichen, der Kern ist überall der gleiche, die Systemperipherie ist > überall identisch, einzig die Anwenderperipherie > (SPI/I2C/UARTS/DMA/Ethernet/...) macht jeder Hersteller wie er will, und > dafür gibts dann auch in der Regel passende Bibliotheken. Okay, das hört sich schon mal gut an, wenn man quasi überall die gleichen Tools verwenden kann. > 5V IOs sind out, 3.3V Single Supply die Regel. Einzig Toshiba hat Cortex > M3 mit 5V. Zusätzliche Kernspannungen (1.2 oder 1.8V) findet man erst > bei ARM9. Okay, SingleSupply wär damit abgehakt. Das 5V out sind, bemerkt man generell durch alle MCUs, aber mir gings primär darum, dass die Eingänge nicht abrauchen, wenn man ein 5V-IC dranhängt. > 3. Debugging > Die günstigen JTAG-Adapter basieren auf dem FTDI FT2232D (Full-Speed) > oder FT2232H (Hi-Speed). Der JLINK ist sehr empfehlenswert - die neueren > Versionen können auch SerialWire, die 2-Draht-Version von JTAG, die > spezifisch für die Cortex-Serie ist. Guuuut, ich hab hier zwei Samples vom FT2232H rumfahren, vielleicht finde ich ja einen Schaltplan zum Nachbasteln :) Werd gleich mal danach suchen... Und damit kann man dann (so gut wie) alle ARMs flashen/debuggen? Welche (Treiber-)Software braucht man dann? > 4. Compiler > Die besten Compiler kommen von ARM/Keil und IAR, aber die Vollversionen > wirst Du nicht bezahlen können. Kommt drauf an. Ich hätte kein Problem damit, in gute Compiler zu investieren. Aber dazu muss ich mir erstmal das Lizenzmodell, Updatepolitik und Funktionsumfang angucken. Ralf
Ralf schrieb: > Kommt drauf an. Ich hätte kein Problem damit, in gute Compiler zu > investieren. Aber dazu muss ich mir erstmal das Lizenzmodell, > Updatepolitik und Funktionsumfang angucken. Obacht. Da geht's in mittlere 4-stellige Regionen, plus jährlichem Obulus. Man muss damit schon seine Brötchen verdienen damit sich das lohnt.
Ralf schrieb: > @fchk: >> 1. Core >> Ich habe mich auf den Cortex M3 konzentriert. Mit ARM7 würde ich nicht >> mehr anfangen, denn der M3 hat etliche Vorteile bezüglich ... > Bezieht sich die Aussage auf die beiden von mir genannten Hersteller? Ja, bis auf Luminary, die sind erst seit dem CM3 dabei. NXP und STM haben das komplette Programm. > Ich dachte, Cortex M3 wird von verschiedenen Herstellern angeboten, bin > ich auf dem falschen Dampfer? Nein > Cortex M3 oder M0 wären so die beiden Cores gewesen, die ich mir > zutraue, an ARM7 dachte ich eigentlich eh nicht. gut. >> 5V IOs sind out, 3.3V Single Supply die Regel. Einzig Toshiba hat Cortex >> M3 mit 5V. Zusätzliche Kernspannungen (1.2 oder 1.8V) findet man erst >> bei ARM9. > Okay, SingleSupply wär damit abgehakt. Das 5V out sind, bemerkt man > generell durch alle MCUs, aber mir gings primär darum, dass die Eingänge > nicht abrauchen, wenn man ein 5V-IC dranhängt. Da mußt Du halt mit Levelshiftern arbeiten. Das ist auch normal. >> 3. Debugging >> Die günstigen JTAG-Adapter basieren auf dem FTDI FT2232D (Full-Speed) >> oder FT2232H (Hi-Speed). Der JLINK ist sehr empfehlenswert - die neueren >> Versionen können auch SerialWire, die 2-Draht-Version von JTAG, die >> spezifisch für die Cortex-Serie ist. > Guuuut, ich hab hier zwei Samples vom FT2232H rumfahren, vielleicht > finde ich ja einen Schaltplan zum Nachbasteln :) Werd gleich mal danach > suchen... Fang bei Olimex an zu suchen... > Und damit kann man dann (so gut wie) alle ARMs flashen/debuggen? Welche > (Treiber-)Software braucht man dann? OpenOCD ist das freie, die kommerziellen Anbieter können diese Teile teilweise auch bedienen. Die Verdrahtung der Hilfssignale ist leider nicht genormt. >> 4. Compiler >> Die besten Compiler kommen von ARM/Keil und IAR, aber die Vollversionen >> wirst Du nicht bezahlen können. > Kommt drauf an. Ich hätte kein Problem damit, in gute Compiler zu > investieren. Aber dazu muss ich mir erstmal das Lizenzmodell, > Updatepolitik und Funktionsumfang angucken. Zur Info: bei Keil geht es um 3k5€, netto natürlich.
Ich bin selbst vor ein paar Monaten von den 8051er auf die ARMs (im Speziellen die STM32-Familie umgestiegen). Ich an deiner Stelle würde mir eine IDE suchen, die dir am Anfang einen möglichst einfachen und barrierelosen Einstieg bietet. Ob du dann später bei der IDE bleibst oder wechselst ist dir dann überlassen. Aber gerade am Anfang wenn der Controller noch neu ist und du am liebsten gleich loslegen willst, sollte die IDE keine unnötigen Steine in den Weg legen. Ich hab den Einstieg mit Keil geschafft, das Debugging funktioniert aber nur bis 32K - dann musst du tief in die Tasche greifen. Nichtsdestotrotz würde ich dir (aus oben genannten Grund) am Anfang dazu raten, ne IDE zu nehmen, "die die Arbeit für dich übernimmt" - also wo du dich nicht mit Linkerscripts..etc herumschlagen musst. Ansonsten wird der Einstieg ziemlich steinig. Da ich bisher nur Erfahrung mit der STM32 Familie habe, bezieht sich der folgende Erfahrungsbericht nur auf diese Mikrocontroller-Familie: ST liefert für die STM32 Familie eine umfangreiche Library mit. Es gibt einige Leute hier im Forum, die mit der Library gerne arbeiten, doch ich bin (im Moment) kein Freund davon. Von den 8051ern war ich es irgendwie gewohnt, den Sourcecode zum Ansteuern der Peripherie (UART, SPI..etc) vor mir zu haben um jederzeit nachschauen zu können was da eigentlich gemacht wird. Bei der Library von ST wird das ganze schon schwieriger und es ist nicht mehr wirklich ersichtlich wie die Peripherie konfiguriert wurde bzw. welche Register von der Initialisierung betroffen sind. Solange du mit der Library den gewünschten Erfolg erzielst, ist alles im Lot. Doch wenn mal etwas nicht so funktioniert wie du dir das vorstellst, dann musst du sowieso auf Registerebene runter und mit dem Reference Manual im Arm dem Fehler auf den Leib rücken. Ich habs mir daher angewöhnt, die Library von ST nur als Unterstützung zum Reference Manual herzunehmen und mir die Routinen selbst zu schreiben. Dauert zwar um einiges länger...aber man bekommt ein Gespür für den Controller und die verwendeten Register.
>aber mir gings primär darum, dass die Eingänge nicht abrauchen, wenn man >ein 5V-IC dranhängt. Zumindest die Cortex M3 von NXP (LPC17xx) haben 5V tolerante Eingänge.
Jörg S. schrieb: >>aber mir gings primär darum, dass die Eingänge nicht abrauchen, wenn man >>ein 5V-IC dranhängt. > Zumindest die Cortex M3 von NXP (LPC17xx) haben 5V tolerante Eingänge. Die STM32 auch, wenn auch nicht alle Pins 5V tolerant sind.
@prx: > Obacht. Da geht's in mittlere 4-stellige Regionen, plus jährlichem > Obulus. Man muss damit schon seine Brötchen verdienen damit sich das > lohnt. Ja, das wollte ich eigentlich vermeiden, vor allem den jährlichen Obulus. Natürlich sehe ich das im Profi-Umfeld ein, aber für den Einstieg ist das natürlich keine Option. Ich werd mich dann erstmal auf die freien konzentrieren. @fchk: > OpenOCD ist das freie, die kommerziellen Anbieter können diese Teile > teilweise auch bedienen. Die Verdrahtung der Hilfssignale ist leider > nicht genormt. Danke, ich werds mir raussuchen. @schluchti: > Ich bin selbst vor ein paar Monaten von den 8051er auf die ARMs (im > Speziellen die STM32-Familie umgestiegen). > Ich an deiner Stelle würde mir eine IDE suchen, die dir am Anfang einen > möglichst einfachen und barrierelosen Einstieg bietet. Hm, die Lite-Version von Atollic könnte ein Anfang sein. Keine Code- oder zeitliche Begrenzung, und natürlich nicht alle Features. Debuggen sollte möglich sein, auch wenn's etwas haarig wird. > Ich hab den Einstieg mit Keil geschafft, das Debugging funktioniert aber > nur bis 32K - dann musst du tief in die Tasche greifen. Hat die Beschränkung einen technischen Hintergrund oder ist das nur zum Kohle machen (würde ich mal vermuten)? > Nichtsdestotrotz würde ich dir (aus oben genannten Grund) am Anfang dazu > raten, ne IDE zu nehmen, "die die Arbeit für dich übernimmt" - also wo > du dich nicht mit Linkerscripts..etc herumschlagen musst. Ansonsten wird > der Einstieg ziemlich steinig. Kann ich mir vorstellen :) Wie gesagt, ich schau mal was ich finde. > ST liefert für die STM32 Familie eine umfangreiche Library mit. Es gibt > einige Leute hier im Forum, die mit der Library gerne arbeiten, doch ich > bin (im Moment) kein Freund davon. > ... > Doch wenn mal etwas nicht so funktioniert wie du dir das vorstellst, > dann musst du sowieso auf Registerebene runter und mit dem Reference > Manual im Arm dem Fehler auf den Leib rücken. Ich habs mir daher > angewöhnt, die Library von ST nur als Unterstützung zum Reference Manual > herzunehmen und mir die Routinen selbst zu schreiben. Dauert zwar um > einiges länger...aber man bekommt ein Gespür für den Controller und die > verwendeten Register. Ah, kein Quellcode für die Libs? Ist zwar schade, aber das wäre auch kein Problem. Ich würde die Libs wahrscheinlich eh immer nur für Testzwecke bzw. quick-n-dirty Inbetriebnahmen verweden. Bei den 8051-Programmen hab ich für gewöhnlich nie Lib-Funktion ála printf o.ä. verwendet, weil man da auch nie weiss, was die genau machen und v.a. blähen die Dinger den Speicherbedarf immer auf. Ich hatte eigentlich eher damit gerechnet, dass ich die Libs als Basis für eigene Quellcodes nutzen kann. Wobei aber auf der ST Homepage steht, dass die Sourcen dabei sind. Naja, wird man sehen. Und auf Registerebene runter zu müssen wär kein Problem, sind wir ja vom 8051 gewöhnt :) Ralf
Ralf schrieb: > Ich werd mich dann erstmal auf die freien konzentrieren. Rowley Crossworks könnte eine Option sein, wenn nichtkommerziell (150$). Basiert wie auch Raisonance Ride technisch auf GCC. Support ist nicht gewährleistet, funktioniert aber trotzdem. > Ah, kein Quellcode für die Libs? Doch, natürlich. Nur Source, keine Binaries. Aber ich halte es auch so wie er schrieb und mache den Kram in vielen Fällen selbst (hochkomplexe Dinge wie USB ausgenommen), denn um die Register kommt man oft sowieso nicht herum. Ausserdem hat sie vom ganzen Aufrufkonzept her eine Neigung zur Umständlichkeit.
A. K. schrieb: > Ralf schrieb: > >> Ich werd mich dann erstmal auf die freien konzentrieren. > > Rowley Crossworks könnte eine Option sein, wenn nichtkommerziell (150$). > Basiert wie auch Raisonance Ride technisch auf GCC. Support ist nicht > gewährleistet, funktioniert aber trotzdem. Noch einen kleinen Kommentar zu RIDE7 / Raisonance. Das einzige was hier codegroessenbeschraenkt ist, das ist der Debugger. Der Compiler kann unbeschraenkt Code erzeugen, man kann auch mit RLink STD unbeschraenkt Code laden / programmieren, lediglich der Debugger limitiert die Groesse auf 32k. Da steckt natuerlich auch massgeblich die Entwicklungsarbeit bei den kommerziellen Anbietern, im Debugger. Fuer den Anfang finde ich nach wie vor den Primer2 eine sehr gute Option. Ein getestetes System fuer den es viel Software gibt. Info zur Hardware Primer2: http://www.mcu-raisonance.com/~primer-starter-kits__microcontrollers__tool~tool__T018:4enfvamuxbtp.html Sehr viel Software in Source fuer den Primer2 gibt es hier: http://www.stm32circle.com . Es gibt auch I/O Extension Boards fuer den Primer2, ebenso wie eine unbeschraenkte Compiler / Debugger version Primer2PRO Zusammenfassend, Rowley fuer den nicht-kommerziellen Gebrauch definitiv anschauen, ein sehr gutes Paket! Raisonance mit Primer2 ist dann ein sehr guter Kandidat, wenn es wirklich in Richtung STM32 gehen soll. Gruss, Robert
@prx: > Rowley Crossworks könnte eine Option sein, wenn nichtkommerziell (150$). > Basiert wie auch Raisonance Ride technisch auf GCC. Support ist nicht > gewährleistet, funktioniert aber trotzdem. Hm, das ist jetzt so ne Sache, wenn ich mir den Primer2PRO hole habe ich zumindest für die ST STM32-Serie eine komplette und vollwertige Entwicklungsumgebung plus "Spielzeug zum Ausprobieren" für etwa den gleichen Preis, und ich darf RIDE dann auch kommerziell nutzen. Oder hab ich das Primer-Paket falsch verstanden? @robertteufel: > Zusammenfassend, Rowley fuer den nicht-kommerziellen Gebrauch definitiv > anschauen, ein sehr gutes Paket! Raisonance mit Primer2 ist dann ein > sehr guter Kandidat, wenn es wirklich in Richtung STM32 gehen soll. Wie bereits erwähnt, der Primer2PRO ist nach meinem Verständnis die volle RIDE-Umgebung für kommerziellen Einsatz für die STM32-Familie. Für die NxP-ARMs gibt es zwar das LPCexpresso, aber das nicht für kommerzielle Zwecke. @fchk: >>> 3. Debugging >>> Die günstigen JTAG-Adapter basieren auf dem FTDI FT2232D (Full-Speed) >>> oder FT2232H (Hi-Speed). Der JLINK ist sehr empfehlenswert - die >>> neueren Versionen können auch SerialWire, die 2-Draht-Version von >>> JTAG, die spezifisch für die Cortex-Serie ist. >> Guuuut, ich hab hier zwei Samples vom FT2232H rumfahren, vielleicht >> finde ich ja einen Schaltplan zum Nachbasteln :) Werd gleich mal danach >> suchen... > Fang bei Olimex an zu suchen... Ich denke, ich werd mal gemäß diesem Dokument: http://www.olimex.com/dev/pdf/ARM-USB-OCD.pdf einen Schaltplan & Board für Eagle zaubern, damit ich etwas universelles habe. Ich schätze, ich werde mir ein Primer2PRO aus o.g. Gründen holen, und falls doch ein Schwenk auf andere Hersteller erfolgt, werde ich versuchen, die freien Tools zu verwenden. Ralf
Ralf schrieb: > Für die NxP-ARMs gibt es zwar das LPCexpresso, aber das nicht für > kommerzielle Zwecke. Ist mir neu, wie kommst du darauf?
@let: >> Für die NxP-ARMs gibt es zwar das LPCexpresso, aber das nicht für >> kommerzielle Zwecke. > Ist mir neu, wie kommst du darauf? Okay, hast recht, lass es mich umformulieren: Für die NxP-ARMs gibt es zwar das LPCexpresso, aber das nicht für kommerzielle Zwecke zum gleichen Preis wie RIDE mit dem Primer2Pro (unter der Annahme, dass man mit dem Primer2Pro Paket tatsächlich kommerziell entwickeln darf). Ralf
Hmm, so wie ich das sehe erlauben beide einen kommerziellen Einsatz. Unterschiede sind: LPCxpresso Base-Board + Modul kosten 102€ netto bei Embedded Artists. Der Debugger hat eine Codegrößenbeschränkung von 128kB, ermöglicht aber den Anschluß externer Controller. Man ist also nicht auf das eine Board festgenagelt. Primer2Pro kostet 129€ netto und hat keine Codegrößenbeschränkung. Ein Einsatz als Entwicklungsumgebung für andere Boards als den Primer ist anscheinend jedoch nicht möglich, da JTAG nicht herausgeführt ist. Sollte es sich bei dem Primer2 tatsächlich um ein geschlossenes System handeln (kann mich ja täuschen), wäre das Teil für mich damit schon gestorben. Da tut es dann auch der billige Primer1, den ich übrigens hier auf dem Schreibtisch liegen habe. (LPCxpresso mit 1768 + 1114 Modul habe ich auch). - Michael PS: Bist du sicher das du nichts mit Ethernet machen willst?
> Hmm, so wie ich das sehe erlauben beide einen kommerziellen > Einsatz. Ah, okay. > Unterschiede sind: > > LPCxpresso Base-Board + Modul kosten 102€ netto bei > Embedded Artists. Der Debugger hat eine Codegrößenbeschränkung > von 128kB, ermöglicht aber den Anschluß externer Controller. > Man ist also nicht auf das eine Board festgenagelt. Das ist ein Vorteil, das stimmt. > Primer2Pro kostet 129€ netto und hat keine Codegrößenbeschränkung. > Ein Einsatz als Entwicklungsumgebung für andere Boards als > den Primer ist anscheinend jedoch nicht möglich, da JTAG nicht > herausgeführt ist. Einen echten Hardware-Guru hält das doch nicht ab, oder? :) > Sollte es sich bei dem Primer2 tatsächlich um ein geschlossenes > System handeln (kann mich ja täuschen), wäre das Teil für > mich damit schon gestorben. Da tut es dann auch der billige > Primer1, den ich übrigens hier auf dem Schreibtisch liegen habe. > (LPCxpresso mit 1768 + 1114 Modul habe ich auch). Hmmmm.... Okay, ich kann ja auch einfach beide Tools kaufen... Aber machen wir bzgl. dem Primer2Pro mal ein kleines Gedankenspiel: Im Schaltplan des Primer2 wird ein weiterer Controller zur Programmierung eingesetzt, mit dem Vermerk "Embedded RLink". Meinst du, der wird firmware-technisch auf die 32k begrenzt sein? Kann ich mir nicht vorstellen, denn dann würde es keine PRO Version geben... Hm... Meinst du das ist ein "voller" RLink? Dann könnte man ja... > PS: Bist du sicher das du nichts mit Ethernet machen willst? Nö, bin ich nicht :) Wer weiss was da an interessanten Sachen und Projekten kommen mag. Warum? Gute Nacht erstmal :) Ralf
Ralf schrieb: > wird ein weiterer Controller zur > Programmierung eingesetzt, mit dem Vermerk "Embedded RLink". Meinst du, > der wird firmware-technisch auf die 32k begrenzt sein? Es gibt ja ein Upgrade vom preiswerten Primer2 auf die Pro Version. Ich schätze das ist nur eine Sache der Ride Software. Bei einer doch recht eingeschränkten Hardwareumgebung kann man mit 32k aber schon eine Menge anstellen. Die Code Dichte des M3 ist höher als bei einem 8-Bitter, die Programme sind also in der Regel kleiner. Der RAM Bedarf ist größer, die 32Bitter haben aber auch mehr davon. Ralf schrieb: >> PS: Bist du sicher das du nichts mit Ethernet machen willst? > Nö, bin ich nicht :) Wer weiss was da an interessanten Sachen und > Projekten kommen mag. Warum? Die Primer sprechen kein Ethernet. Ein weiterer Grund für einen der kleineren Primer Versionen: Speicherhungriger Netzwerkcode wird mangels Hardware nicht benötigt ;)
Hallo Michael, > Es gibt ja ein Upgrade vom preiswerten Primer2 auf die Pro Version. > Ich schätze das ist nur eine Sache der Ride Software. Ja, aber in dem Fall müsste vom Primer die Info kommen, ob es ein embedded RLink STD oder PRO ist. Ich dachte jetzt halt spontan daran, einen Primer2PRO zu kaufen, den on-board RLink zu isolieren und einen low-cost RLink zu haben :) > Bei einer doch recht eingeschränkten Hardwareumgebung kann man mit 32k aber > schon eine Menge anstellen. Die Code Dichte des M3 ist höher als > bei einem 8-Bitter, die Programme sind also in der Regel kleiner. Gut, so hatte ich das auch verstanden. Und ich hatte bis jetzt nur wenige 8-Bit-Apps mit mehr als 32k, sollte also wunnebar passen. > Der RAM Bedarf ist größer, die 32Bitter haben aber auch mehr davon. Warum? Hängt das mit der Busbreite und solchen Alignment-Sachen etc zusammen? Ralf
Nachtrag: > Die Primer sprechen kein Ethernet. Ein weiterer Grund für einen > der kleineren Primer Versionen: Speicherhungriger Netzwerkcode > wird mangels Hardware nicht benötigt ;) Naja, Ethernet mag vielleicht mal interessant werden, aber momentan eher nicht. Und bis dahin wird sich sicherlich wieder was auf dem Primer-Markt getan haben... :) Ralf
Ralf schrieb: >> Der RAM Bedarf ist größer, [...] > Warum? Hängt das mit der Busbreite und solchen Alignment-Sachen etc > zusammen? Diese Vermutung hängt mit dem Alignment zusammen, das bei vielen 32bit RISC Architekturen eingeschränkt ist. Alle Cortex-M Prozessoren[1] unterstützen aber unaligned access. D.h. globale Variablen und Strukturelemente können an beliebiger Adresse im Speicher liegen. Lediglich beim Stack ist das Alignment eingeschränkt. Übersetzt man beliebigen Code, dann ist es wahrscheinlich, dass z.B. ein Cortex-M die Speichergröße nicht so effizient nutzt, wie im Fall von speziell zu diesem Zweck optimiertem Code. -- Marcus Footnotes: [1] Genaugenommen alle ARM Prozessoren, seit der v6 Architektur
Ralf schrieb: >> Der RAM Bedarf ist größer, die 32Bitter haben aber auch mehr davon. > Warum? Hängt das mit der Busbreite und solchen Alignment-Sachen etc > zusammen? Auch. Zwar ist der Cortex-M3 dabei ggf. zu Lasten der Performance flexibler als ARM7 - der kleinere als 8/16-Bit Ersatz platzierte Cortex-M0 jedoch nicht! - aber typischerweise achten Compiler dennoch auf passendes Alignment. Dann sind im RAM platzierte Adressen natürlich 4 Bytes breit. Ebenfalls trägt dazu bei, dass Register auch dann 32 Bits breit sind, wenn davon nur 8 Bits notwendig wären, und ein auf dem Stack gesichertes Register folglich mehr Platz benötigt. In Vergleich dazu sind Register beim Maschinenmodell des avr-gcc effektiv 16 Bits breit und die fast durchweg statisch adressierten Variablen eines 8051-Derivats oft nur 8 Bit.
A. K. schrieb: > In Vergleich dazu sind Register beim Maschinenmodell des avr-gcc > effektiv 16 Bits breit und die fast durchweg statisch adressierten > Variablen eines 8051-Derivats oft nur 8 Bit. Korrektur: Das passt so formuliert eher auf die praktisch registerlosen 68xx und PICs. Aber die 8051-Compiler dürften im Unterschied zu avr-gcc kein quasi 16-bittiges Registermodell verwenden. Wie sich andere AVR Compiler verhalten weiss ich nicht, avr-gcc jedenfalls neigt dazu, den grosszügig dimensionierten Registersatz auch grosszügig zu nutzen, was etwas mehr RAM kosten kann als zwingend nötig.
A. K. schrieb: > Zwar ist der Cortex-M3 dabei ggf. zu Lasten der Performance > flexibler als ARM7 - der kleinere als 8/16-Bit Ersatz platzierte > Cortex-M0 jedoch nicht! Du hast natürlich recht. Die v6-M Architektur (Cortex-M0/M1) unterstützt keine unaligned Zugriffe. -- Marcus
Ralf schrieb: > einen Schaltplan & Board für Eagle zaubern, damit ich etwas universelles > habe. Der J-Link von Segger für privaten Gebrauch kostet meines Wissens nur 59,00€ und kann alles. Es gibt keine mir bekannte Beschränkung und ist damit auch universell. Da hst du ein professionielles Werkzeug mit guter SW-Unterstützung dabei. Ist nur ein Tip. Für 59,00€ sich soviel Arbeit machen? Es sei denn du hast Spaß daran. Dann ist es was anderes.
A. K. schrieb: > Zwar ist der Cortex-M3 dabei ggf. zu Lasten der Performance > flexibler als ARM7 - der kleinere als 8/16-Bit Ersatz platzierte > Cortex-M0 jedoch nicht! Oha, Danke für den Hinweis. Ich verwende sowohl M0 als auch M3. Den kleinen bisher nur in einer Schaltung ohne Pointer getrickse aber das hätte bestimmt irgendwann geknallt ;).
Meine Empfehlung: ... kauf dir ein funzendes eval-board mit dem ARM derivat deiner wahl mit standard jtag anschluss, yagarto (gcc+eclipse) als C-toolchain und den Jlink von Segger in der privat-version (very erschwinglich, unterstützt gdb+debugging in eclipse + flashen + flash-breakpoints). damit hast du keine limitierungen+abhängigkeiten für später, eclipse ist inzwischen ein quasi-standard als IDE und Jlink als debug-adapter unterstützt eigentlich alles was du brauchst zum einstieg und für später. Damit hast Du schmerzfrei eine funzende entwicklungsplattform und kannst anhand funktionierender beispiele die entwicklungsumgebung kennenlernen und dann anfangen das 51'er zeugs zu portieren ;-). gruss, tom.
Michael G. schrieb: > Oha, Danke für den Hinweis. Ich verwende sowohl M0 als auch M3. > Den kleinen bisher nur in einer Schaltung ohne Pointer getrickse > aber das hätte bestimmt irgendwann geknallt ;). Das hätte möglicherweise so oder so geknallt, da einige Befehle bei allen Cores ein bestimmtes Alignment voraussetzen. Der Compiler versucht Zugriffe zu optimieren und lotet die Möglichkeiten anhand des Datentyps aus. Wenn da getrickst wird (und man diverse Feinheiten der Zielarchitektur nicht beachtet), kann das leicht in die Hose gehen. Beispiel: Du hast ein char[], das an beliebiger Adresse stehen kann. Du weißt, dass das eigentlich aus int32_t besteht. Einen beherzten Typecast nach int32_t später, und der Compiler denkt sich "Prima, kann man ja zum kopieren ein LDRD/STRD, oder LDM/STM verwenden". Das war's dann auch schon, da beide Befehle Wort-alignment voraussetzen. Die Möglichkeit, in HW unaligned Zugriffe ausführen zu können, macht es lediglich etwas effizienter, aber meist nicht sicherer, auf derartige Daten zuzugreifen. -- Marcus
Das ist großartig! Dann ist der M3 als ARM7 Nachfolger ja noch sinnloser als ich dachte ;) Die Hardwaredivision benutzt der GCC recht selten. Div durch eine Konstante geht per Software anscheinend schneller. Und der NVIC hat doch bestimmt auch irgendeinen Haken! Das Arbeitspferd ist hier nach wie vor der LPC23xx bzw. LPC2478. LPC11x/13xx ersetzen nur PICs und AVRs. Der Tag ist gerettet :)
Michael G. schrieb: > Das ist großartig! Nein, sinnlos. Die Art der Speicherzugriffe (aligned oder nicht) hätte sicherlich nicht die höchste Priorität bei der Auswahl meines Prozessors. > Die Hardwaredivision benutzt der GCC recht selten. Div durch eine > Konstante geht per Software anscheinend schneller. Kommt auf die Konstante an, denke ich. Und wenn Codegröße im Vordergrund steht, haben UDIV/SDIV auch bei Konstanten (außer Zweierpotenzen und ähnliche Trivialfälle) ihre Vorzüge. > Und der NVIC hat doch bestimmt auch irgendeinen Haken! Auf jeden Fall. Er ist anders! -- Marcus (smileys erkannt)
Michael G. schrieb: > Die Hardwaredivision benutzt der GCC recht selten. Das hängt eher vom Anwender ab als vom Compiler. > Und der NVIC hat doch bestimmt auch irgendeinen Haken! Bin jedenfalls noch nicht drüber gestolpert. Vielleicht der Umstand, dass es ein bissel dauert, bis man den NVIC komplett verstanden hat. Er ist doch etwas komplexer als die VICs der LPC2000.
Michael G. schrieb: > Das ist großartig! Dann ist der M3 als ARM7 Nachfolger ja noch > sinnloser als ich dachte ;) Sind dir unaligned accesses so wichtig? Immerhin gibt's bei den Cortexen einen Hardfault beim missglückten Versuch. Die älteren ARMs liefern statt dessen nur "interessante" Ergebnisse.
A. K. schrieb: >> Die Hardwaredivision benutzt der GCC recht selten. > > Das hängt eher vom Anwender ab als vom Compiler. So ist es meistens ;). Bei mir ist der Divisor aber fast immer konstant. >> Und der NVIC hat doch bestimmt auch irgendeinen Haken! > > Bin jedenfalls noch nicht drüber gestolpert. Ich gebe die Hoffnung nicht auf! > Sind dir unaligned accesses so wichtig? Nö, man muß es eigentlich nur wissen. ARM hat dieses Feature aber auf der Werbetafel stehen. Und doch muß man aufpassen was der Compiler treibt. Wie beim ARM7. > Immerhin gibt's bei den Cortexen > einen Hardfault beim missglückten Versuch. Mist ;)
Hallo zusammen, schön zu sehen, dass sich hier auch ARM-Anwender untereinander gleich mal verständigen, da kann man das eine oder andere noch rauslesen (als Anfänger zwar etwas schwierig zu erfassen, um was es konkret geht, aber trotzdem gut). Macht ruhig weiter :) Ralf
Macht es eigentlich einen Unterschied, ob man den Cortex-M3 in C oder C++ programmiert? Bei Crossworks hat man z.B. ja die Wahl zwischen beidem.
blub schrieb: > Macht es eigentlich einen Unterschied, ob man den Cortex-M3 in C oder > C++ programmiert? Wäre doch irgendwie komich, wenn da kein Unterschied wäre ;-). C++ geht, nur kann es sein, das bestimmte C++ features wie exception handling nicht oder nicht vollständig implementiert sind. Nur ist man dann stärker festgelegt, C++ Compiler sind weniger verbreitet.
Michael G. schrieb: > So ist es meistens ;). Bei mir ist der Divisor aber fast immer > konstant. Siehe meinen Hinweis oben. >> Sind dir unaligned accesses so wichtig? > Nö, man muß es eigentlich nur wissen. ARM hat dieses Feature > aber auf der Werbetafel stehen. Und doch muß man aufpassen was > der Compiler treibt. Wie beim ARM7. Nun ja, der Prozessor bewahrt Dich natürlich nicht vor Programmierfehlern ("Pointer getrickse"). Die Vorteil auf beliebige Daten (<=32bit) an beliebigen Adressen, und zwar ohne den worst case annehmen zu müssen, mit einem Befehl zugreifen zu können ist nicht von der Hand zu weisen und vor allem neu in den low-end ARM Prozessoren. Man spart somit etwas RAM (kein padding nötig) ohne gleichzeitig den Flash Bedarf zu erhöhen, da die gleiche Zahl von Instruktionen benötigt wird. -- Marcus
Hallo zusammen, vielen Dank für eure Beiträge, sehr interessant :) Meine Entscheidung ist momentan auf die NxP Familie gefallen, genauer gesagt habe ich mir die LPCxpresso-Boards für den LPC1114 und LPC1343 bestellt. Gründe hierfür waren einerseits der Preis von 20-25€ / St. sowie das mitgelieferte und vor allem separat verwendbare Programmier-/Debuginterface und andererseits die m.E. recht großzügige "Beschränkung" der LPCxpresso/REDSuite IDE von 128kB. Der STM Primer2(PRO) ist aber nicht abgeschrieben, sondern nur "verschoben". Mit Display, Touchscreen, und allem drum und dran inkl. "Betriebssystem" sicherlich gut geeignet für richtig große Projekte, aber als 8051-Umsteiger wahrscheinlich oversized und v.a. leider keine Möglichkeit selbstgebastelte Schaltungen zu programmieren/debuggen. Momentan lese ich mich in die ARM-AppNote bzgl. Wechsel vom 8051 zum Cortex-M3 ein (http://infocenter.arm.com/help/topic/com.arm.doc.dai0237a/DAI0237A_migrating_from_8051_to_Cortex_M.pdf). Wer noch weitere Empfehlungen für "Migranten" hat, nur her damit :) Und falls jemand "Anfänger"-Links oder Quellen für interessante eBooks/PDFs hat, wär das natürlich auch nicht schlecht. Gute Nacht Ralf
Ralf schrieb: > Hallo zusammen, > > vielen Dank für eure Beiträge, sehr interessant :) > .......snip ........ > Der STM Primer2(PRO) ist aber nicht abgeschrieben, sondern nur > "verschoben". Mit Display, Touchscreen, und allem drum und dran inkl. > "Betriebssystem" sicherlich gut geeignet für richtig große Projekte, > aber als 8051-Umsteiger wahrscheinlich oversized und v.a. leider keine > Möglichkeit selbstgebastelte Schaltungen zu programmieren/debuggen. Tja, dann schau doch mal das Erweiterungsboard an: http://www.raisonance.com/~stm32-primer2-add-on-modules-with-wrapping-area__microcontrollers__product~product__T017:4dsue907qx6.html Gibts bei Watterott als Einzelstueck zu kaufen. http://www.watterott.com/de/STM32-Primer2-Add-On-Module Also die eigenen Versuche gehen sehr wohl. Man kann sogar was kleines dranpacken und das ganze immer noch im Gehaeuse verstecken, muss allerdings dann recht klein sein. Gruss, Robert
Marcus Harnisch schrieb: > Beispiel: Du hast ein char[], das an beliebiger Adresse stehen kann. Du > weißt, dass das eigentlich aus int32_t besteht. Einen beherzten Typecast > nach int32_t später, und der Compiler denkt sich "Prima, kann man ja zum > kopieren ein LDRD/STRD, oder LDM/STM verwenden". Das war's dann auch > schon, da beide Befehle Wort-alignment voraussetzen. Das kann auch auf anderen Systemen schief gehen. Wer so programmiert, hat es nicht anders verdient.
@RobertTeufel: Moin, danke für den Hinweis, aber das ist nicht das was ich gemeint habe. "Selbstgebastelte Schaltungen" heisst komplett selbstgebastelt :) Ein Devkit o.ä. als Basis herzunehmen, um erstens sofort ein lauffähiges System zu haben und probieren/erweitern zu können, bevor man die endgültige Hardware aufbaut ist super, aber irgendwann will halt auch die Hardware programmiert werden :) Aber Watterott sieht interessant aus, vielleicht find ich da noch andere interessante Sachen. Ralf
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.