mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Einstiegshilfe in ARM-Controller


Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bernhard B. (schluchti)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg S. (joerg-s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Christoph Budelmann (Firma: Budelmann Elektronik GmbH) (christophbudelmann) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Robert Teufel (robertteufel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...
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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Michael G. (let)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Michael G. (let)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Michael G. (let)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Helmut Ru (heru01)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
abo

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael G. (let)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;).

Autor: tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael G. (let)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael G. (let)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: blub (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.d...). 
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

Autor: Robert Teufel (robertteufel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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-mo...
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

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.