Hallo,
ich spiele gerade mit dem Gedanken, aus der AVR-Welt kommend die Nase
mal in ARM zu stecken.
Bei der Suche nach einer IDE stoße ich auf CooCox und CoIDE, und im Wiki
steht dazu auf der LPC1xxx Seite: "einem chinesischen Open-Source
Projekt".
Hmmmm - das Chinesische daran ist wohl, dass es geklaut und keineswegs
Open Source ist? Jedenfalls kann ich keinen Quelltext finden, und im
CooCox Forum beschweren sich einige Anwender darüber, dass alles nur
binär für Windows zur Verfügung steht.
Übersehe ich da etwas?
Oder ist dies tatsächlich nur ein parasitäres Projekt?
Dann käme es für mich nicht in Frage.
Was genau wird als Open Source aufgeführt? Auf der Homepage bezieht sich
dieser Begriff auf Libraries, Treiber und RTOS. Nicht auf die
Entwicklungsumgebung jenseits des Compilers. Dass es sich beim Compiler
um GCC handelt ist völlig legitim.
Andere verwenden aber auch GCC als Grundlage. Und nicht immer so, wie
GNU sich das gedacht hat. Microchip tut das in etwas grenzwertiger Form,
die an Methoden von Rechtsverdrehern erinnert. Deren 16- und 32-Bit
Umgebungen basieren auf GCC, dem sie zusätzliche Optimierungen
beigebracht haben, ohne diese als Quellcode zu veröffentlichen. Das
haben sie dadurch legal erreicht, indem sie den Compiler zwischendurch
quasi aufbrechen, die Optimierungen mit einem separaten Programm auf dem
Zwischencode durchführen, um dann mit dem Rest vom GCC darauf basierend
wieder weiter zu machen. Soviel zu "Chinesen im Geiste".
AVR-Bastler schrieb im Beitrag #4428960:
> Oder ist dies tatsächlich nur ein parasitäres Projekt?
Hallo:
Was ist ein "parasitäres Projekt" ?
Gruß
Marc
AVR-Bastler schrieb im Beitrag #4428960:
> ich spiele gerade mit dem Gedanken, aus der AVR-Welt kommend die Nase> mal in ARM zu stecken.
Zum Nase reinstecken kannst du doch auch die Demoversionen der
"professsionellen System" nehmen.
Wenn du mit "freeware --> Malware,...." Probleme hast ;-)
A. K. schrieb:> Auf der Homepage bezieht sich> dieser Begriff auf Libraries, Treiber und RTOS. Nicht auf die> Entwicklungsumgebung jenseits des Compilers
Wenn ich das richtig sehe, wird ein verändertes Eclipse verwendet,
dessen Quelltext nicht veröffentlicht wird.
AVR-Bastler schrieb im Beitrag #4429036:
> Wenn ich das richtig sehe, wird ein verändertes Eclipse verwendet,> dessen Quelltext nicht veröffentlicht wird.
Das stünde wohl im Widerspruch zur Lizenz von Eclipse (EPL): "A
Contributor may choose to distribute the Program in object code form
under its own license agreement, provided that: [...] iv) states that
source code for the Program is available from such Contributor, and
informs licensees how to obtain it in a reasonable manner on or through
a medium customarily used for software exchange."
Marc schrieb:> Wenn du mit "freeware --> Malware,...." Probleme hast ;-)
Nein, ich habe mit Freeware keine Probleme. Aber Freeware und Open
Source sind zwei völlig verschiedene Paar Schuhe.
Natürlich gibt es Menschen, die alles, was sie im Leben interessiert
(Mikrocontroller, Auto, Haus, Frau, Kinder), nur nach dem Preis in Euro
bewerten - für diese Leute gibt's da natürlich keinen Unterschied, da
beides kostenlos ist.
> Was ist ein "parasitäres Projekt" ?
Open-Source beruht auf Geben + Nehmen.
Parasiten sind solche, die gegen den Willen des Wirts nehmen und nichts
zurück geben (außer Antikoagulanzien, Boreliose, usw.)
A. K. schrieb:> Das stünde wohl im Widerspruch zur Lizenz von Eclipse (EPL
Ja, genau das ist der Kritikpunkt im CooCox Forum.
Da CooCox sagt, dass sie keine Linux-Version planen, gab es offenbar
Interesse, einen Port zu machen - aber CooCox schweigt auf Fragen zum
Quelltext.
Jojo S. schrieb:> Für die LPC1xxx ist das LPCXpresso von NXP auch sehr gut zu> gebrauchen.
Danke!
Ich habe mal reingeschaut: Quelltext der offenen Komponenten ist dabei,
läuft unter Linux.
Nachteil: Sobald man mal einen Chip von STM verwenden will, muss man
wohl die IDE wechseln. Wieso eigentlich? Ich denke, die ARM sind alle
gleich?
AVR-Bastler schrieb im Beitrag #4428960:
> ich spiele gerade mit dem Gedanken, aus der AVR-Welt kommend die Nase> mal in ARM zu stecken.>> Bei der Suche nach einer IDE stoße ich auf
Hä?
Was willst du eigentlich?
Du behauptest, "die Nase mal in ARM zu stecken" und als allererstes
fängst du an, mit der Suche nach irgend einer IDE. Das hat mit "Nase in
ARM" so viel zu tun wie die Kuh mit dem Fliegen. Anschließend kommt hier
eine Diskussion auf über Opensource/Freeware/Befindlichkeiten und so.
Das hat mit dem "Nase in Arm" noch viel weniger zu tun.
Also, wenn du es tatsäüchlich ernst meinst und hier nicht bloß
herumtrollen willst, dann lade dir die Dokus zu den diversen aktuellen
Arm-Architekturen von arm.com herunter und fange dann an mit Lesen -
damit du verstehst, wohinein du deine Nase stecken willst. Aktuell sind
so etwa Cortex M0, M0+, M3 und M4 bzw. M4F - ja es gibt noch viel mehr,
aber die Genannten sind so etwa das, was für dich am ehesten in Frage
kommt. Am ehesten würde ich dir zu einem Cortex M4F raten, denn der hat
sowohl DSP als auch Gleitkomma intus und kostet auch nicht viel mehr als
die anderen genannten.
Als nächstes würde ich dir zur Demoversion vom "Keil" raten. Solange du
keine Riesenprojekte angehst, reicht die dir erstmal aus und du hast nen
professionellen Compiler zur Verfügung. Einen normalen Editor wirst du
ja wohl besitzen, also brauchst du nur noch eine simple Batchdatei zum
Kompilieren und fertig ist die Soße. Jede (wirklich JEDE) IDE macht im
vergleich dazu nur einen Haufen Schaumschlägerei, was dich von deinem
eigentlichen Ziel ablenkt.
Zum Schluß guck dir einen µC aus, der einen eingebauten Bootlader hat -
irgend ein LPCxyz von NXP zum Beispiel. Mit so einem Teil kriegst du
deine selbstgeschriebenen Ergüsse am einfachsten in den Chip. Jetzt
werden gleich wieder einige schreiben, daß es ohne JTAG/SWD ja garnicht
geht, weil sie ja nur dann etwas zuwege bringen können, wenn sie auch
debuggen können - um herauszukriegen, was der Compiler aus ihrem
Kauderwelsch gemacht hat.
Die Alternative wäre ein Seggerscher J-Link aus China oder ein
J-Link-Edu nebst geklauter Flash-Lizenz - aber ob du das willst, mußt du
selber entscheiden. Wieder weden jetzt einige schreiben, daß man ja auch
mit einem FTDI-Chip und OpenOCD sich befassen könnte - aber das ist
ebenfalls mehr Gefummel im Abseits als daß es nützt zu "Nase in ARM".
W.S.
AVR-Bastler schrieb im Beitrag #4429317:
> Ich denke, die ARM sind alle> gleich?
Im Kern ja, aber die Peripherie ist unterschiedlich und vor allem wie
der interne Flash programmiert wird.
Den Compiler kann man schon für µCs anderer Hersteller nutzen, aber der
Support beim Debuggen fehlt und der Komfort was z.B. Linkerfiles
erstellen fehlt weil NXP nur die Daten seiner MCUs integriert hat.
AVR-Bastler schrieb im Beitrag #4429317:
> Nachteil: Sobald man mal einen Chip von STM verwenden will, muss man> wohl die IDE wechseln. Wieso eigentlich?
Naja, NXP "verschenkt" ja die IDE, zumindest in der freien Version, die
IMHO bis 256 kB Code kann. Dass die jetzt da keinen Support für STM (für
die Konkurrenz) einbauen, ist ja naheliegend. Der gcc kann aber
natürlich erstmal Code für alle Cortexe generieren, eclipse kann die
auch (mit den geeigneten Plugins) unterstützen.
AVR-Bastler schrieb:> ich spiele gerade mit dem Gedanken, aus der AVR-Welt kommend die Nase> mal in ARM zu stecken.
Lektion Nr. 1:
W.S. schrieb:> Was willst du eigentlich?
Nicht auf das wirre Geschreibsel von W.S. hören, das er dir bei jedem
Beitrag zu Cortex-M um die Ohren haut.
Hier gibt es eine Auswahl an Entwicklungsumgebungen, keiner zwingt dich
CooCox zu verwenden:
https://www.mikrocontroller.net/articles/STM32#Freie_Software.2FFreeware
Hier gibt es beispielsweise ein Tutorial für eclipse+GCC für sowohl
Linux+Windows: STM32 Eclipse JLink Linux/Windows. Außer der
JLink-Software ist daran alles Open-Source. Dafür hast du mit JLink auch
den schnellsten Debugger auf dem Markt, unterstützt die deutsche
Wirtschaft und hast 1A Linux Support ;-) Alternativ kannst du auch
OpenOCD + ST-Link nehmen, dann ist es 100% Open Source.
W.S. schrieb:> also brauchst du nur noch eine simple Batchdatei zum> Kompilieren und fertig ist die Soße. Jede (wirklich JEDE) IDE macht im> vergleich dazu nur einen Haufen Schaumschlägerei, was dich von deinem> eigentlichen Ziel ablenkt.
Aber eigene Batchdateien machen und Libraries zusammen suchen lenkt
nicht ab? Wenn du empfiehlst, Keil nur als Compiler zu benutzen, und die
ganzen "Vorteile" nicht zu nutzen, kannst du auch gleich den GCC
empfehlen, denn der ist Open Source, geht unter Linux, kann neueste
Sprachstandards (C++11), und hat kein 32kB-Code-Limit.
W.S. schrieb:> Jetzt> werden gleich wieder einige schreiben, daß es ohne JTAG/SWD ja garnicht> geht, weil sie ja nur dann etwas zuwege bringen können, wenn sie auch> debuggen können - um herauszukriegen, was der Compiler aus ihrem> Kauderwelsch gemacht hat.
Richtig erkannt. Der W.S. ist ein Genie der Programmen (ggf im Assembler
Code) alle Fehler ansehen kann, inklusive dem was die Peripherie so
macht. Da 99% der Entwickler aber keinen Röntgenblick haben, ist es für
diese enorm hilfreich einen echten Debugger zu haben. Dieser hilft -
insbesondere wenn die Projekte mehr als 100 Zeilen haben - sehr dabei
Fehler schneller(!) zu finden. Wenn man schon weg vom AVR will, kann man
auch gleich die Vorteile vom ARM genießen, wie eben richtiges Debugging.
W.S. schrieb:> Die Alternative wäre ein Seggerscher J-Link aus China
Der dann bald nicht mehr funktioniert wenn die JLink-Software ein
Firmware-Upgrade macht bzw. die geklaute Serien-Nr. erkennt
W.S. schrieb:> oder ein> J-Link-Edu nebst geklauter Flash-Lizenz
J-Flash brauchts nicht, denn im Hobby-Bereich will man wohl kaum
Massen-Programmierung betreiben. Für einfaches Flashen reicht auch
J-Flash Lite (gratis) oder einfach die JLink-Kommandozeile (auch
gratis). Gerade W.S. sollte sich doch über Kommandozeile ohne
Klicki-Bunti-freuen!
AVR-Bastler schrieb im Beitrag #4429317:
> Nachteil: Sobald man mal einen Chip von STM verwenden will, muss man> wohl die IDE wechseln. Wieso eigentlich? Ich denke, die ARM sind alle> gleich?
Zwar basieren die Microcontroller von Hersteller wie NXP, ST
Microelectronics usw. meistens auf denselben ARM-Kernen, die diese
Hersteller eben bei ARM eingekauft haben. Bezüglich der Ausgestaltung
der Peripherieblöcke gibt es jedoch erhebliche Unterschiede. Bei den
Cortex-basierten Prozessoren/Controllern gibt es zwar von ARM ein paar
Vorgaben (CMSIS-"Standard"), aber die Bausteine sind eben nicht 1:1
austauschbar.
Die Prozessorhersteller stellen heutzutage gerne ein paar IDEs oder
Bibliotheken kostenlos bereit, um damit die Kunden an ihre Produkte zu
binden. Liest man sich nämlich die Lizenzbedingungen durch, stellt man
sehr schnell fest, dass dort sinngemäß steht: "Ihr könnt alles mit
unseren Bibliotheken anstellen, solange sie nicht auf Produkten von
Fremdherstellern eingesetzt werden". Solche Bedingungen sind auch sehr
gut nachvollziehbar, denn schließlich hat der Hersteller (oder die von
ihm beauftragte Softwarebude) auch viel Geld und Zeit hineingesteckt.
Grenzwertig sind aber in der Tat Produkte, deren Open-Source-Herkunft
verschleiert und/oder die Lizenzbestimmungen nicht eingehalten werden.
Zuguterletzt muss man auch immer fragen, wer denn überhaupt gegen wen
einen Anspruch auf Herausgabe der Quellen oder einen
Unterlassungsanspruch besitzt. Es ist keineswegs so, dass jeder diese
Ansprüche durchsetzen kann. Im Zweifelsfall können nur die Autoren der
ursprünglichen Software irgendetwas durchsetzen. Wenn Organisationen wie
z.B. gpl-violations.org gegen einen Rechtsverletzer vorgehen wollen,
müssen sie immer mindestens einen Autor mit an Bord haben.
Als Konkurrenzunternehmen hat man ggf. noch die Chance, auch ohne
Beteiligung eines Autors vorzugehen, nämlich auf wettbewerbsrechtlichem
Wege, wenn ein Anbieter die OS-Herkunft seiner Software nicht
ordnungsgemäß (d.h. den jeweiligen Lizenzbedingungen entsprechend)
kennzeichnet.
Dr. Sommer schrieb:> Dafür hast du mit JLink auch> den schnellsten Debugger auf dem Markt, unterstützt die deutsche> Wirtschaft und hast 1A Linux Support ;-)
Kannst Du bitte eine seriöse Quelle nennen, die den JLink im Vergleich
zu einem Lauterbach ICD getestet hat und zu solch einem pauschal
gültigen Ergebnis gekommen ist? Ich meine damit nicht irgendeinen
Hochglanzprospekt von Segger.
Die anderen Merkmale (deutsches Produkt, erstklassiger Linux-Suppprt,
und zwar sowohl für Linux-Hosts als auch -Targets) treffen nämlich auch
auf Lauterbach zu.
Nachtrag:
Ich wollte ursprünglich noch scherzhaft gefragt haben, ob Lauterbach
denn auch noch DEC VMS unterstützt. Ein Blick auf die Homepage ergibt,
dass sie in der Tat noch VMS sowohl auf Alpha als auch VAX
unterstützen... Das nenne ich 'mal Produktpflege!
Wir haben eine mittlerweile knapp zehn Jahren alte Debugger-Hardware von
Lauterbach, die aber auch heute noch für alle aktuellen Prozessoren
unterstützt wird. Wir mussten nur zwischendurch einen neuen Stecker mit
Pegelwandler kaufen, wodurch es möglich wäre, auch Prozessoren mit 0,7V
Kernspannung zu debuggen.
Wenn ich Auto fahren möchte fange ich auch nicht damit zu lernen wie der
Motor konstruiert ist. Für einen Anwender ist für mich die Nutzung einer
IDE nix Verwerfliches.
Wenn man Erfahrungen mit anderen IDEs hat kommt man mit LPCXpresso oder
Keil µVision gut zurecht. Bei LPCXpresso ist anfangs nur die Fülle an
Optionen erschlagend, dafür sollte man das mitgelieferte User Guide
durchsehen.
Als JTAG Debugger kann ich den LPCLink-2 empfehlen, der kann JTAG und
SWD. Per Firmware kann man den CMSIS-DAP oder J-Link kompatibel machen,
damit verträgt der sich z.B. auch mit CooCox.
Hallo,
Schau doch mal die STM32 Reihe und die Evalboards dazu an. Die
Discoveryboards sind sehr günstig und haben schon einen integrierten
Debugger mit dabei.
Ich habe mich damals für STM32F4Discocery entschieden, da dieser massig
Speicher, VIELE Timer (17 PWM Kanäle), DSP und eine FPU hat. Außerdem
ist ein AudioDAC, sowie ein Beschleunigungssensor an Board. Riesen
Vorteil ist eben, dass ein ST-Link V2 Debugger/Flasher an Board ist.
http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/PF252419?sc=internet/evalboard/product/252419.jsp
Als Toolchain würde ich GCC nehmen.
Gründe:
- Sehr aktuell (Kann C++11)
- kostenlos/OpenSource
- Viele andere professionelle IDEs nutzen auch den GCC
- Viele Tutorials im Netz
Falls du dich zusätzlich noch in ein RTOS einarbeiten möchstes dann
schau dir unbedingt ChibiOS an. Das ist ein OpenSource RTOS besonders
für die STM32 Reihe.
ChibiStudio ist ein Paket aus Eclipse + GCC + Tools für eben ChibiOS und
STM32. Einfach nur downloaden und loslegen. Du kannst statt der RTOS
Demos auch einfach "Bare-Metal" programmieren und einfach nur die
Toolchain nutzen.
http://www.chibios.org/dokuwiki/doku.php?id=chibios:product:chibistudio:start
Andreas S. schrieb:> Kannst Du bitte eine seriöse Quelle nennen, die den JLink im Vergleich> zu einem Lauterbach ICD getestet hat und zu solch einem pauschal> gültigen Ergebnis gekommen ist?
Leider nicht. Weißt du ob der Lauterbach schneller ist? Es scheint
allgemein wenig Informationen zu dem im Netz zu geben. Wäre auch ein
Argument dagegen... ;-) Scheint auch hier im Forum bzw. allgemein der
Hobby-Community kaum vertreten zu sein. Aber um die Wahl des
Debug-Adapters gings hier eigentlich gar nicht...
Versuchs doch mal mit "TrueStudio lite" wenn dein Chip unterstützt wird.
Für den Einstieg reichts und anders als viele anderen Bastel-IDEs läuft
es Out-Of-The-Box. Glaube es hat keine Code-Begrenzung, nur einige
Debug-Features kosten extra $$$.
Dr. Sommer schrieb:> Aber eigene Batchdateien machen und Libraries zusammen suchen lenkt> nicht ab?
Guck dir die Lernbetty an, da kannst du sehen wie man sowas macht - jaja
auch du kannst daraus noch was lernen. Hast du eigentlich jemals was
anderes gemacht als naseweises Zeug von dir gegeben? Du nervst bloß.
Aber zurück zum Thema:
Ich sehe durchaus, daß es ne Menge Leute gibt, die am liebsten in irgend
einer IDE herumklicken wollen, wobei es ihnen eigentlich eher
nebensächlich ist, worauf sich diese IDE bezieht.
Und da es mittlerweile eben hipp geworden ist, von sich ganz laut sagen
zu können "Hört mal alle her, ICH BEFASSE MICH MIT A_R_M", kommt eben
das Nachfragen nach der hippesten IDE für Arm auf.
Es ist ja jedem unbenommen, sich genau damit zu befassen, was ihm denn
so in den Sinn kommt, zum Beispiel eben das Herumdaddeln in einer
Verfinsterung (Eclipse) oder so.
Aber aus böser Erfahrung weiß ich, daß die meisten, die so anfragen,
sich später als Entwicklungsingenieure bewerben und in vollstem Stolz
von sich behaupten, daß sie sich mit 32 Bit Controllern bestens
auskennen - obwohl sie mal grad irgend ein HelloWorld mittels LPCxpresso
oder dergleichen hingekriegt haben und von all dem, was sie eigentlich
können sollten, keinen Schimmer haben. Und unsereiner muß dann binnen 6
Monaten - ach lassen wir das, dazulernen muß jeder, der in ne Firma
kommt, aber man sollte besser von vornherein wissen, worauf man sich
einläßt, sonst verplempert jeder nur seine Zeit.
So also, jedem Tierchen sein Plaisierchen, deswegen meine begründete
Frage, was der TO denn eigentlich will.
W.S.
W.S. schrieb:> Guck dir die Lernbetty an, da kannst du sehen wie man sowas macht
Hab ich doch schon, und dir doch schon erläutert was daran alles falsch
ist. Ich erinnere mich an so grausame Dinge wie Makros für
Typdefinitionen zu verwenden.
W.S. schrieb:> jaja auch du kannst daraus noch was lernen.
Ja, was für verrückte Leute es gibt.
W.S. schrieb:> Du nervst bloß.
Aber du nicht?
Warum überhaupt batch files und keine makefiles? Ist doch viel zu
langsam und nervig. Und es ist ja schön dass du alles auf der Konsole
mit direktem Compileraufruf kompilieren kannst. Ja, das kann ich und
viele andere auch. Das ist noch lange kein Grund sich deswegen besonders
cool zu fühlen, und zu behaupten dass man mit einer IDE, die das
automatisch macht, nicht viel schneller ist.
W.S. schrieb:> Aber aus böser Erfahrung weiß ich, daß die meisten, die so anfragen
Jaja blablabla alle sind doof außer mir, aber das hat nichts damit zu
tun dass es zur Steigerung der Produktivität durchaus sinnvoll ist,
IDE's und Debugger zu nutzen.
Jojo S. schrieb:> Wenn ich Auto fahren möchte fange ich auch nicht damit zu lernen wie der> Motor konstruiert ist. Für einen Anwender ist für mich die Nutzung einer> IDE nix Verwerfliches.
Diese Art zu diskutieren ist sachlich falsch. Ich erläutere es dir mal:
Wenn deine Tochter sich nen MP3-Player kauft, um damit ihre
allerneuesten Songs zu hören, dann ist es ihr zu Recht völlig wurscht,
ob darin ein Arm oder ein grünes Marsmännchen werkelt. Das Ding muß bloß
die Songs ordentlich abspielen. Deine Tochter ist Anwender.
Wenn du hingegen ein Entwicklungsingenieur sein willst, der "sich mit
ARMs befaßt", dann mußt du dich zwangsweise mit den Innereien des Chips
befassen, auch damit, was man damit machen kann und wo seine Grenzen
liegen, wie tatsächlich was geht und so weiter. Du bist eben nicht
Anwender wie deine Tochter mit ihrem MP3-Player. Deshalb ist deine
Argumentation sachlich falsch.
Ansonsten ist das Verwenden einer IDE durchaus nichts Verwerfliches, man
ist ja kein Extremist, gelle?
Aber mit dem Vorhaben zu starten "ich spiele gerade mit dem Gedanken,
aus der AVR-Welt kommend die Nase mal in ARM zu stecken" und dann
komplett an der Zielrichtung vorbeizurennen und sich auf irgend eine IDE
stürzen zu wollen, ist ein schwerer Fehler am Anfang von Allem, auf den
man so einen Beginner hinweisen muß, wenn man ihn nicht verscheißern
will.
W.S.
W.S. schrieb:> So also, jedem Tierchen sein Plaisierchen, deswegen meine begründete> Frage, was der TO denn eigentlich will.>> W.S.
Ich denke außer Dir ist das wohl jedem klar.
Dies hier könnte ein guter Startpunkt für einen STM32 Anfänger sein.
http://www.carminenoviello.com/en/2014/12/28/setting-gcceclipse-toolchain-stm32nucleo-part-1/
Er hat auch ein Script womit sich per Cube erzeugte Projekte in Eclipse
importieren lassen.
Wenns nicht Eclipse sein soll fand ich EmBitz auch sehr nett, das
einzige Problem dabei ist der Projektimport von Cube.
Gruß Stephan
Wenn ich an einem Projekt arbeite nutze ich zu 99 % den Editor in der
IDE, was hat das mit 'herumdaddeln' in einer IDE zu tun? Anfangs kommen
die Projekteinstellungen wie MCU Auswahl, Suchpfade und Defines
einstellen dazu. Und sich mit gcc Einstellungen in Makefiles herumplagen
hat nichts mit ARM Programmierung zu tun.
So ein STM32 Disco Board habe ich, ST verteilt die ja wie Kamelle zu
Karneval. Für den Einbau in eigene, kleine Sachen waren mir die immer zu
fett und da reichen mir kleinen LPC11xx oder 13xx.
Mittlerweile gibt es aber auch die STM32F103 beim Chinesen, so ein
http://de.aliexpress.com/item/STM32F103C8T6-ARM-STM32-Minimum-System-Development-Board-Module-ForArduin/32282374854.html
Board (mit 64 Karat Flash!) habe ich gerade hier liegen. Die kommen
damit preislich schon in die Arduino Nano Region.
Die 103er haben aber nur 16 Bit Timer, da treibt mich gerade ein Fehler
in der mbed lib in den Wahnsinn, die 32 Bit Timer/Counter im LPC sind
echt ein Seegen! Warum ist man bei ST so geizig und macht die nicht auch
alle gleich 32 Bit breit?
Dr. Sommer schrieb:> Leider nicht. Weißt du ob der Lauterbach schneller ist?
Ich habe auch keinen Benchmark zur Hand. Außerdem muss man sich die
genauen Anwendungsfälle anschauen. Geht es bei der Geschwindigkeit um
das Programmieren eines internen Flashes? Oder um das Auslesen von
Speicherinhalten? Oder Traces?
Ein riesiger Vorteil der Lauterbach-Debugger besteht darin, dass man
neben den eingebauten Algorithmen zum Programmieren/Auslesen von
Speicherinhalten auch eigene im Speicher des Prozessors ablegen kann
(sog. Target Based Programming). Damit kommt man auch an unkonventionell
angeschlossenen Speicher heran. Das ist bei den heutigen
vollintegrierten Microcontrollern vielleicht nicht so relevant, bei
Systemen mit extern angeschlossenem Speicher aber ggf. schon.
> Es scheint allgemein wenig Informationen zu dem im Netz zu geben.> Wäre auch ein Argument dagegen... ;-)
Die mitgelieferte bzw. für Kunden per Download erhältliche Dokumentation
einschließlich Beispielcode bzw. -skripten ist schon so umfangreich,
dass da kaum noch Fragen offen bleiben.
> Scheint auch hier im Forum bzw. allgemein der> Hobby-Community kaum vertreten zu sein.
Das ist hauptsächlich eine Kostenfrage. Je nach Trace- oder
Logikanalysefunktion kostet die Hardware ca. 2kEUR bis 10kEUR. Zudem
muss man für jede Prozessorkernfamilie eine eigene Lizenz kaufen, d.h.
ARM7 benötigt eine Lizenz, ARM9 eine weitere, Cortex-M noch eine,
Cortex-A eine, jeweils mit Kosten von rund 1kEUR.
Lauterbach ist aber recht großzügig mit Testlizenzen.
W.S. schrieb:> Diese Art zu diskutieren ist sachlich falsch. Ich erläutere es dir mal:
falsch finde ich es Leuten die nach einer IDE fragen das makefile zu
predigen und sie als Daddler zu bezeichnen wenn sie ein anderes Werkzeug
wählen.
IDE oder makefile sind Werkzeuge die man im Hobbybereich selber wählen
kann und erfreulicherweise gibt es da heute eine große Auswahl für die
man früher viel Geld hinlegen musste.
Andreas S. schrieb:> Geht es bei der Geschwindigkeit um> das Programmieren eines internen Flashes? Oder um das Auslesen von> Speicherinhalten? Oder Traces?
Ersteres, und die Geschwindigkeit von Step-by-Step-Debugging würde ich
sagen...
Andreas S. schrieb:> Ein riesiger Vorteil der Lauterbach-Debugger besteht darin, dass man> neben den eingebauten Algorithmen zum Programmieren/Auslesen von> Speicherinhalten auch eigene im Speicher des Prozessors ablegen kann
Ja, das klingt in der Tat cool...
Andreas S. schrieb:> Die mitgelieferte bzw. für Kunden per Download erhältliche Dokumentation> einschließlich Beispielcode bzw. -skripten ist schon so umfangreich,> dass da kaum noch Fragen offen bleiben.
Tja, ich hätte mir erstmal eine Übersichts-Website mit den Features
gewünscht, und kein 1000-Seitiges PDF. Gibts beim JLink ja auch :-)
Andreas S. schrieb:> Das ist hauptsächlich eine Kostenfrage. Je nach Trace- oder> Logikanalysefunktion kostet die Hardware ca. 2kEUR bis 10kEUR.
Aah, damit hat sich das für den Hobbybereich wohl erledigt?!
W.S. schrieb:> Wenn du hingegen ein Entwicklungsingenieur sein willst, der "sich mit> ARMs befaßt", dann mußt du dich zwangsweise mit den Innereien des Chips
Man muss aber nicht als allererstes alle Details lernen. Fängt man erst
mit den Innereien des IC's an, und damit wie man den Compiler per Batch
aufruft, kommt man nie auf einen grünen Zweig. Die Motivation hat sich
dann (für den Hobby-Entwickler) auch schnell erledigt. Es ist durchaus
sinnvoll, es sich ersteinmal einfach zu machen mit IDE's und Libraries,
und sich die Grundlagen der Peripherie anzusehen (wie zB die
Gemeinheiten des RCC beim STM32), und dann stück für stück
vorzuarbeiten. Es kriegt keiner eine Medaille weil er von Anfang an den
kompliziertesten Weg gewählt hat...
Jojo S. schrieb:> Im Kern ja, aber die Peripherie ist unterschiedlich und vor allem wie> der interne Flash programmiert wird.> Den Compiler kann man schon für µCs anderer Hersteller nutzen, aber der> Support beim Debuggen fehlt
OK, das macht Sinn.
W.S. schrieb:> Aber aus böser Erfahrung weiß ich, daß die meisten, die so anfragen,> sich später als Entwicklungsingenieure bewerben und in vollstem Stolz> von sich behaupten, daß sie sich mit 32 Bit Controllern bestens> auskennen
Ich hatte auch einmal ganz üble Erfahrungen mit einem externen
Mitarbeiter gemacht, der sich angeblich genau mit dem damals
eingesetzten Mikroprozessor (AT91RM9200) auskannte und angeblich auch
ein Linux-Experte war. Im Laufe des Projektes zeigten sich jedoch so
eklatante Wissenslücken, dass das Projekt komplett in die Hose gegangen
war. Glücklicherweise hatten wir entsprechende Klauseln in den
Entwicklungsvertrag aufgenommen, so dass zu dem fachlichen Desaster für
mich nicht auch noch ein finanzielles hinzukam. Das größte Problem
dieses Mitarbeiters war seine Lernresistenz, d.h. er hatte ziemlich
wirre Vorstellungen von der Funktionsweise des Prozessors und sah es als
Fehler des Prozessors an, wenn sich dieser nicht so verhielt wie von ihm
erwartet. Selbiges traf noch mehr auf Linux zu. Ständig glaubte er,
eklatante Fehler im Kernel gefunden zu haben, aber er selbst war bloß
nicht in der Lage, die APIs richtig zu verwenden.
Der Typ hatte damals rund 30 Jahre Berufserfahrung, d.h. natürlich einen
erheblichen Teil auf uralten UNIX-Systemen und Mainframes.
Andreas S. schrieb:> Grenzwertig sind aber in der Tat Produkte, deren Open-Source-Herkunft> verschleiert und/oder die Lizenzbestimmungen nicht eingehalten werden.
Darum ging es mir hier.
Ich kaufe weder Raubkopien von kommerzieller Software noch benutze ich
Software, die eine FOSS Lizenz verletzt. Da ist es mir völlig
gleichgültig, dass beide Raubkopien ja doch "kostenlos" sind, und mit
"Freeware" hat weder das eine noch das andere etwas zu tun.
Ich achte die Lizenzen (so ungewöhnlich das manchen auch scheinen mag.)
Daher wollte ich wissen, ob ich das mit CooCox richtig einschätze.
Nun sind ganz nebenbei aus diesem Thread noch viele Empfehlungen für den
ARM-Einstieg und interessante IDEs herausgekommen.
Danke dafür an:
Jojo S. (jojos)
Dr. Sommer (Gast)
Total Eclipse (Gast)
m. keller (Gast)
kderh (Gast) (auch wenn TrueStudio auf meinem OS vermutlich nicht
laufen wird)
AVR-Bastler schrieb im Beitrag #4429509:
> Ich kaufe weder Raubkopien von kommerzieller Software noch benutze ich> Software, die eine FOSS Lizenz verletzt.
Oha, das ist aber ein hoher Anspruch. Ich bezweifele, dass sich die
zweite Aussage wirklich durchhalten lässt. Wie die Vergangenheit gezeigt
hat, haben sich auch schon große Markenhersteller entsprechende
Lizenzverstöße erlaubt. Die allermeisten Fälle werden auch komplett
unentdeckt bleiben, nämlich dann, wenn nur eine Bibliothek rechtswidrig
eingesetzt wird und die Verwendung dieser Bibliothek von außen nicht
erkennbar ist. Da bleibt eigentlich nur der vollständige Verzicht auf
jegliche Elektronik.
> Da ist es mir völlig> gleichgültig, dass beide Raubkopien ja doch "kostenlos" sind, und mit> "Freeware" hat weder das eine noch das andere etwas zu tun.> Ich achte die Lizenzen (so ungewöhnlich das manchen auch scheinen mag.)
Neben den recht einfach zu definierenden Urheberrechtsverstößen können
aber auch noch andere Schutzrechte beeinträchtigt sein, z.B. Patente
oder Muster.
> Daher wollte ich wissen, ob ich das mit CooCox richtig einschätze.
Deine Sichtweise auf CooCox ist rassistisch geprägt. Nur weil es sich
mittlerweile um ein chinesisches Projekt handelt, unterstellst Du
automatisch Rechtsverstöße. Weißt Du, aus welchem anderen Land außer
China die meisten Plagiate stammen? Richtig, Deutschland!
Man wird aber in der Tat niemals eine international einheitliche
Würdigung geistigen Eigentums erreichen können. In vielen asiatischen
Kulturen gilt die Anfertigung von Plagiaten als Ehre gegenüber dem
ursprünglichen Ersteller. Ganz im Gegensatz hierzu steht die
US-amerikanisch geprägte Sichtweise, die auch in Deutschland stark
dominiert, dass jeder noch so kleine Furz in bare Münze umsetzbar sein
muss.
Meine persönliche Einsstellung hierzu ist, dass wir ein starkes Urheber-
und Markenrecht benötigen, um konkrete Produkte zu schützen und
Nachahmer erkennen zu können. Im Gegenzug sollte der Patentschutz sehr
viel schwächer sein, d.h. Trivialpatente dürfen sich nicht lohnen. Die
Dauer des Patentschutzes muss sich zudem an dem Zeitbedarf für die
Erfindung orientieren.
Dr. Sommer schrieb:> Nicht auf das wirre Geschreibsel von W.S. hören
Danke auch für diesen Tipp - wenngleich Du ihn selbst danach nicht sehr
konsequent befolgst... ;-)
Ich folge diesem Forum schon eine ganze Weile. Es gibt viele gute
Beiträge und viele sachkundige Teilnehmer.
Zwar wird es manchmal durch gewisse andere Teilnehmer sehr anstrengend -
damit meine ich nicht (nur) oder nicht einmal speziell W.S.
Ich nehme an, hier ist einfach eine Sektion des "Fanclubs für
leistungsloses Grundeinkommen" beheimatet. Aber man muss ja auch die
gesellschaftliche Funktion eines solchen Forums berücksichtigen.
"Inklusion" nennt man das wohl heute.
(Man stelle sich nur vor, was die armen Teufel ohne Forum so treiben
würden... Eisenbahnschienen durchsägen, Flüchtlingsheime anzünden,
abends ohne Hose durch den Stadtpark laufen...)
AVR-Bastler schrieb im Beitrag #4429317:
> Ich denke, die> ARM sind alle gleich?
Es gibt keine "die ARM".
Gleich ist bei Microcontroolern, welche auf dem selben ARM Cortex
basieren eben nur der. Das heisst die Controller sind änlich, denn die
Perepherie um diesen CPU Kern herum gestaltet jeder anders.
W.S. schrieb:> Die Alternative wäre ein Seggerscher J-Link aus China oder ein> J-Link-Edu nebst geklauter Flash-LizenzHust...dir ist klar das Segger hier auch mitliest?
Kannst ja selber entscheiden inwieweit sowas für dich strafrechtlich
relevant ist.
Davon abegesehen, das bei 50,- Euro für eine J-link EDU es keinen Grund
mehr gibt sich einen Clon aus China zu besorgen.
Guest schrieb:> Hust...dir ist klar das Segger hier auch mitliest?
Logo. Was meinst du eigentlich, weswegen ich elleweil auf das
Programmieren der Chips mittels eingebautem Bootlader hinweise?
Jaja, ich bin ein großer Freund von Chips mit fest eingebautem Bootlader
- und das aus zwei mir wichtigen Gründen:
1. Der Bootlader weiß ganz genau, wie eben dieser Chip zu
programmieren ist.
2. Der Bootlader ist im Lieferumfang des Chips enthalten und ein jeder
kann ihn benutzen ohne dafür irgendwas zu bezahlen.
und 3.: Punkt 1 und 2 sind bei allen JTAG/SWD-Lösungen nicht enthalten,
sondern eher das Gegenteil.
Klaro?
Aber - und das stellt sich beim Lesen dieses threads mal wieder heraus,
ist der Eröffnungspost nicht wirklich ernst gemeint. Stattdessen geht es
wie immer vorrangig um das Ausprobieren von IDE's, welche die hippeste
IDE ist. Na denne, macht mal...
W.S.
Etwas OT...
A. K. schrieb:> Andere verwenden aber auch GCC als Grundlage. Und nicht immer so, wie> GNU sich das gedacht hat. Microchip tut das in etwas grenzwertiger Form,> die an Methoden von Rechtsverdrehern erinnert.
Volle Zustimmung
> Deren 16- und 32-Bit> Umgebungen basieren auf GCC, dem sie zusätzliche Optimierungen> beigebracht haben, ohne diese als Quellcode zu veröffentlichen.
Quelltexte gibt es schon
http://www.microchip.com/pagehandler/en-us/devtools/dev-tools-parts.html
ganz unten unter Source Archives
> Das> haben sie dadurch legal erreicht, indem sie den Compiler zwischendurch> quasi aufbrechen, die Optimierungen mit einem separaten Programm auf dem> Zwischencode durchführen, um dann mit dem Rest vom GCC darauf basierend> wieder weiter zu machen. Soviel zu "Chinesen im Geiste".
Anscheinend reicht es den Compiler entweder selbst zu erstellen (mit
entsprechenden Anpassungen) oder einen der im Netz auffindbaren Patche
zu nutzen, um die "Erweiterungen" von Microchip, die wohl nur die
Optimierungen bei mangelnder Lizenz ausschalten, zu umgehen...
Arc N. schrieb:> Quelltexte gibt es schon> http://www.microchip.com/pagehandler/en-us/devtools/dev-tools-parts.html> ganz unten unter Source Archives
Den aus GPL Quellen abgeleiteten Teil müssen sie veröffentlichen. Jener
Microchip-eigene Optimizer, auf den ich mich beziehe, ist aber nicht
Teil des Exe-Programms des Compilers, sondern in ein separates
Exe-Programm ausgelagert. Dadurch entfällt die Pflicht zur
Veröffentlichung des Quellcodes dieses Teils.
> Anscheinend reicht es den Compiler entweder selbst zu erstellen (mit> entsprechenden Anpassungen) oder einen der im Netz auffindbaren Patche> zu nutzen, um die "Erweiterungen" von Microchip, die wohl nur die> Optimierungen bei mangelnder Lizenz ausschalten, zu umgehen...
Der Lizenzcheck selbst kann aus Lizenzgründen nicht Teil eines
Exe-Programms sein, das aus den GCC Quellen abgeleitet ist - ihn als
Quellcode zur Verfügung zu stellen wäre einigermassen absurd. Folglich
ist der Lizenzcheck auch ein separates Exe-Programm. Dessen Ergebnis
entscheidet darüber, ob der Compiler mit voller oder eingeschränkter
Lizenz arbeitet. So wars jedenfalls vor einigen Jahren.
W.S. schrieb:> Aber - und das stellt sich beim Lesen dieses threads mal wieder heraus,> ist der Eröffnungspost nicht wirklich ernst gemeint.
Doch, er war ernst gemeint. Du hast die Frage nur nicht gelesen.
(Kleiner Tipp: Fragen stehen in den Sätzen, die mit diesem Zeichen
enden: "?".)
Statt dessen hast Du eine Frage beantwortet, die ich nicht gestellt
hatte, von der Du Dir aber gewünscht hast, dass ich sie gestellt hätte,
nämlich wie man sich am besten dem Thema ARM nähert.
Damit hast Du eine von mir nicht beabsichtigte Sekundär-Diskussion
angestoßen, die aber am Ende durch die Beiträge der anderen Nutzer
tatsächlich auch für mich fruchtbar und informativ war.
Dafür danke ich Dir.
Nach Deiner freundlichen Einleitung:
W.S. schrieb:> Hä?>> Was willst du eigentlich?
habe ich Dich jedoch zunächst ignoriert.
Meine durchaus ernst gemeinte Frage war, ob CooCox und CoIDE eine Lizenz
verletzen.
Das mag für Dich nicht wichtig oder sogar unverständlich sein, weil
geklaut ja schließlich nix kostet, aber für mich ist es wichtig.
Denn
- Raubkopie
- Freeware
- Open Source
sind drei völlig verschiedene Dinge. Ja, alle drei sind "kostenlos".
Aber rechtlich sind Welten dazwischen.
Und auch wenn ich mich für ARM interessiere - so "arm" bin ich nicht,
dass ich es mir nicht leisten könnte, das Recht als Grundlage unserer
Gesellschaft zu achten.
W.S. schrieb:> Als nächstes würde ich dir zur Demoversion vom "Keil" raten
Wird auf meinem OS wohl nicht laufen.
W.S. schrieb:> brauchst du nur noch eine simple Batchdatei zum> Kompilieren und fertig ist die Soße.
Ja, ich weiß. Habe ich auch mal gemacht. Irgendwann in den 80er Jahren
des vergangenen Jahrhunderts. Komplilieren und Linken auf der
Kommandozeile. Waaahnsinnig spannend. Leider wenig abwechslungsreich.
Inzwischen bin ich faul genug für eine IDE. Ja, ich gebe es offen zu:
Ich bin sogar so faul, dass ich bei manchen Programmier-Aufgaben
Bibliotheken benutze, statt alles komplett neu zu schreiben!
Hineinschauen kann man ja trotzdem mal- das soll auch bei der Anwendung
von Bibliotheksfunktionen helfen.
W.S. schrieb:> aus böser Erfahrung weiß ich, daß die meisten, die so anfragen,> sich später als Entwicklungsingenieure bewerben
Nein, ganz sicher nicht. Man weiß zwar nie, was einem im Leben noch so
alles zustoßen mag, Schicksalsschläge, sozialer Abstieg,... und ich
möchte auch den hier vetretenen Entwicklungsingenieuren nicht zu nahe
treten, aber ich kann mir wirklich kein Szenario vorstellen, in dem ich
mich irgendwo als "Entwicklungsingenieur" bewerben würde.
Und noch eine Antwort auf einen O.T. Beitrag, eigentlich alles für den
Bereich "Gesellschaft & Soziales":
Hallo Andreas,
Andreas S. schrieb:> Ich bezweifele, dass sich die> zweite Aussage wirklich durchhalten lässt.
Sie lässt sich genauso leicht durchhalten wie die erste.
Auch die Verwendung von Raubkopien, raubkopierten Teilen oder Plagiaten
kann verschleiert werden. Daraus aber abzuleiten, dass man dann genauso
gut Raubkopien kaufen kann, weil man auch sonst ja nicht
hundertprozentig sicher vor Betrug sein kann... schräg, oder?
Mit derselben Logik könnte man ja einen Ladendiebstahl damit
rechtfertigen, dass es ja nicht auszuschließen ist, dass es sich sowieso
nur um Hehlerware gehandelt hat.
Andreas S. schrieb:> Deine Sichtweise auf CooCox ist rassistisch geprägt. Nur weil es sich> mittlerweile um ein chinesisches Projekt handelt, unterstellst Du> automatisch Rechtsverstöße.
Das ist ja ein dicker Hund!
Ich habe auf www.coocox.org quelloffene Software gefunden, die als
"free/open" angeboten wird. Die Seite hat eine .org Domain, nicht .cn.
Dann stelle ich fest, dass die zum größten Teil aus der Linux-Welt
stammenden quelloffenen Komponenten nur als Windows-Executable angeboten
werden. Ist ja kein Problem - da nimmt man sich die Source und
kompiliert das eben für die eigene Umgebung neu.
Allerdings habe ich vergeblich nach den Quellen gesucht. Nun kann es ja
sein, dass ich sie nur nicht gefunden habe. Nicht alle Webseiten sind
übersichtlich...
Wie Du aus meiner Frage nun Rassismus herleitest, bleibt Dein Geheimnis.
Vielleicht solltest Du Deine eigenen vorschnellen Schlüsse noch einmal
hinterfragen, bevor Du auf den Knopf "Absenden" klickst.
Über die mangelnde Patentfähigkeit von Trivialpatenten, lebenden
Organismen, in der Natur vorhandener Information usw. können wir uns
sicher verständigen. Aber Recht darf nicht vom "kulturellen Hintergrund"
abhängen. Sonst wären Ehrenmorde nicht strafbar. Aber wenn ich jemanden
umbrächte, wäre es strafbar. Es sei denn es war ein Grüner, und ich kann
nachweisen, dass ich ein CSU-Parteibuch habe. Dann wird man wieder sagen
"Bayern halt... kulturelle Unterschiede."
Andreas S. schrieb:> Die> Dauer des Patentschutzes muss sich zudem an dem Zeitbedarf für die> Erfindung orientieren.
Das wiederum halte ich für völligen Blödsinn. es würde dazu führen, dass
eine Bremsbirne, die 20 Jahre gebraucht hat, um etwas patentierbares
zuwege zu bringen, einen höheren Patentschutz genießt, als eine Genius,
der pro Tag 10 gute Einfälle hat und verwirklicht.
Leistung = Arbeit / Zeit
und eben nicht
Leistung = Arbeit * Zeit
Das ist dasselbe Argument, mit dem der Arbeiter, der jeden Tag Kisten
von links nach rechts und wieder von rechts nach links schleppt, voll
Hass und Neid auf den "Manager" schaut, der diese sinnlose Tätigkeit
einfach streicht. Der Arbeiter hat schließlich den ganzen Tag
gearbeitet, und dieser Schnösel da sitzt bloß in seinem Büro...
A. K. schrieb:> Folglich> ist der Lizenzcheck auch ein separates Exe-Programm. Dessen Ergebnis> entscheidet darüber, ob der Compiler mit voller oder eingeschränkter> Lizenz arbeitet. So wars jedenfalls vor einigen Jahren.
Das tut der Lizenzcheck auch noch...
Ohne direkt auf die möglichen Umgehungen zu verlinken:
Im Source des Gcc ist gut auffindbar u.a. untergebracht: Laden des
Lizenzchecksprogramms, Testen ob dessen Hash zu dem im Quelltext
vorgegebenen Hashwert passt, falls ja, Lizenzprogramm ausführen und je
nach Rückgabewert die entsprechende(n) Lizenz(en)/Optimierungsstufe(n)
freischalten bzw. falls etwas davon nicht funktioniert hat die
Optimierungen ausschalten und jeweils entsprechende Meldungen
ausgeben... Der Quelltext des Gcc darf entsprechend der GPL verändert
und weitergegeben werden...
Arc N. schrieb:> Lizenzchecksprogramms, Testen ob dessen Hash zu dem im Quelltext> vorgegebenen Hashwert passt,
Der Check mit dem Hashwert war früher noch nicht drin.
A. K. schrieb:> Arc N. schrieb:>> Quelltexte gibt es schon>> http://www.microchip.com/pagehandler/en-us/devtools/dev-tools-parts.html>> ganz unten unter Source Archives>> Den aus GPL Quellen abgeleiteten Teil müssen sie veröffentlichen. Jener> Microchip-eigene Optimizer, auf den ich mich beziehe, ist aber nicht> Teil des Exe-Programms des Compilers, sondern in ein separates> Exe-Programm ausgelagert. Dadurch entfällt die Pflicht zur> Veröffentlichung des Quellcodes dieses Teils.
Beim XC32 finde zumindest ich nichts in diese Richtung. Bin aber auch
eher weniger mit den gcc-Quelltexten vertraut... Mit grep und anhand der
offensichtlichen Dateinamen ist nur die Lizenzteststelle auffällig (was
zumindest mit anderen Quellen im Netz übereinstimmt...)
Ich hatte das vor etlichen Jahren beim Compiler für die dsPIC30
festgestellt. Microchip hatte eine eigene Optimierung zur
Zusammenfassung von gleichen Codeschnipseln eingebaut, um Code zu sparen
(auch im damaligem Compiler für PIC18 fand sich diese
Optimierungtechnik). Ob die auch in der PIC32 Version drinsteckt weiss
ich nicht.
np r. schrieb:> Doch, er war ernst gemeint. Du hast die Frage nur nicht gelesen.> (Kleiner Tipp: Fragen stehen in den Sätzen, die mit diesem Zeichen> enden: "?".)
Oh danke für die Aufklärung.
Aber es bleibt dabei: Dein Eröffnungsbeitrag (sofern du denn überhaupt
der TO bist) war ganz sicher nicht wirklich ernst gemeint.
Ich zitiere mal:
"ich spiele gerade mit dem Gedanken, aus der AVR-Welt kommend die Nase
mal in ARM zu stecken."
Ah ja, die Nase in Arm stecken. Bin beeindruckt von soviel Präzision in
der Aussage.
np r. schrieb:> Statt dessen hast Du eine Frage beantwortet, die ich nicht gestellt> hatte, von der Du Dir aber gewünscht hast, dass ich sie gestellt hätte,> nämlich wie man sich am besten dem Thema ARM nähert.
Ähemm.. eben genau DAS hatten wir doch im Eröffnungspost. Also, wo
willst du denn deine Nase hineinstecken, he?
> Nach Deiner freundlichen Einleitung:> W.S. schrieb:>> Hä?>>>> Was willst du eigentlich?>> habe ich Dich jedoch zunächst ignoriert.
Das ist dein Problem - nicht das meinige.
Wer da meint, es ohne meinen Rat besser zu können.. bittesehr, nur zu,
rein theoretisch führen 1000 Wege nach Rom.
np r. schrieb:> Komplilieren und Linken auf der> Kommandozeile. Waaahnsinnig spannend. Leider wenig abwechslungsreich.
Und wer es partout nicht einfach und geradlinig mag, sondern lieber
verzwickt, dem sei auch dieses gegönnt.
Fazit:
Dein Interesse an "Nase in Arm stecken" ist gleich null, stattdessen
willst du eine Diskussion über CooCox und CoIDE und lizenzrechtliche
Themen.
Warum schriebest du das denn nicht gleich im Eröffnungspost? (wieder
vorausgesetzt, du bist dessen Schreiber)
W.S.
Lieber W.S.,
> Ah ja, die Nase in Arm stecken. Bin beeindruckt von soviel Präzision in> der Aussage.
Ja, endlich! Hier hast Du es endlich erfasst . aber leider selbst nicht
gemerkt.
Es war eine Aussage, keine Frage.
Wenn ich schreibe:
"Heute ist das Wetter so schlecht, da möchte ich wieder etwas löten.
Welche Lötstation nehmt ihr?"
dann ist der einleitende Teil über das Wetter eine Aussage,
möglicherweise nicht sehr präzise, aber belanglos, denn eben nur eine
Einleitung.
Die Frage ist das Ding mit dem Fragezeichen "?".
Du hast also auf die Aussage geantwortet anstatt auf die Frage. weil
Dir die Aussage zu unpräzise war und Du unbedingt belehren wolltest!
LOL :-D
Nein, sorry. Man sollte da nicht lachen. So ein Verhalten ist ja eher
traurig und kann schnell einsam machen.
> stattdessen willst du eine Diskussion über CooCox und CoIDE und lizenzrechtliche> Themen.> Warum schriebest du das denn nicht gleich im Eröffnungspost?
Genau das habe ich getan. Dies war nämlich die Frage und mit einem
Fragezeichen deutlich gekennzeichnet.
Du siehst: Wer lesen kann ist klar im Vorteil.
> sofern du denn überhaupt der TO bist
Fragen stelle ich oft anonym. Da ist ja nur die Frage wichtig und nicht,
wer sie stellt.
Wenn ich Dich persönlich aneiere, dann mache ich das mit Login.
Ich weiß, dass manche andere das genau umgekehrt handhaben, aber das mag
ich nicht.
